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j  rl  SjZ-J  j 

'9-fri  this  paper  we  dioaugg  extensions  to  the  conventual  relational  algebra  to  support  both 
aspects  of  transaction  time,  evolution  of  a  databases  contents  and  evolution  of  a  database’s 
scheme.  W<*  define  a  relation’?  scheme  to  be  the  relation’s  temporal  signature,  a  function 
mapping  the  relation’s  attribute  names  onto  their  value  domains,  and  class,  indicating  the 
extent  of  support  for  time.  We  also  introduce  cojnmands  to  change  a  relation,  now  defined  as  a 
triple  consisting  of  a  sequence  of  classfes,  a  sequence  of  signatures,  and  a  sequence  of  states.  A 
semantic  type  system  is  required  tfi  identify  semantically  incorrect  expressions  and  to  enforce  , 
consistency  constraints  among  a  relation’s  class,  signature,  and  state  following  update.  We- 
-a i&ow  that  these  extensions  are  applicable,  without  change,  to  historical  algebras  that  support 
valid  time,  yielding  an  algebraic^anguage  for  the  query  and  update  of  temporal  databases.  The 
additions  preserve  the  useful  properties  of  the  conventional  algebra.  ^ 


A  database  scheme  describes  the  structure  of  the  database;  the  contents  of  the  database 
must  adhere  to  that  structure  [Date  1976,  Ullman  1982].  Scheme  evolution  refers  to  changes  to 
the  scheme  of  a  database  over  time.  Conventional  databases  allow  only  one  scheme  to  be  in  force 
at  a  time,  requiring  restructuring  (also  termed  logical  reorganization  [Sockut  &  Goldberg  1979]) 
when  the  scheme  is  modified.  With  the  advent  of  databases  storing  past  states  [McKenzie  1986], 
it  becomes  desirable  to  accommodate  multiple  schemes,  each  in  effect  for  an  interval  of  time  in  the 
past. 


In  an  earlier  paper  [McKenzie  tz  Snodgrass  1987 A]  we  proposed  extensions  to  the  conven¬ 
tional  relational  algebra  [Codd  1970]  that  model  the  evolution  of  a  database’s  contents.  We  did 
not,  however,  consider  the  evolution  of  a  database’s  scheme.  In  this  paper,  we  provide  further 
extensions  to  the  conventional  relational  algebra  that  model  the  evolution  of  a  database’s  scheme. 
The  extensions  that  support  evolution  of  a  database’s  contents  are  repeated  here  for  completeness 
and  because  the  extensions  supporting  scheme  evolution  are  best  explained  in  concert  with  those 
earlier  extensions. 


1  Approach 


Languages  for  database  query  and  update  exist  at  no  less  than  three  levels  of  database  abstraction. 
At  the  user-interface  level,  calculus -based  languages  such  as  SQL  are  available  for  expressing  query 
and  update  operations.  At  the  algebraic  level,  the  relational  algebra  is  the  formal,  abstract  language 
for  expressing  these  same  operations.  Finally,  at  the  physical  level,  query  and  update  operations  can 
be  defined  in  terms  of  data  structures  and  access  strategies.  In  this  paper  we  focus  on  language 
definition  at  the  algebraic  level.  Our  goal  here  is  to  define  formally  an  algebraic  language  for 
database  query  and  update  that  supports  evolution  of  a  database’s  scheme,  as  well  as  its  contents. 
To  do  so,  we  extend  the  relational  algebra  to  handle  one  aspect  of  time  in  databases. 

Time  must  be  added  to  the  underlying  data  model  before  it  can  be  added  to  the  relational 
algebra.  In  previous  papers,  we  identified  three  orthogonal  aspects  of  time  that  a  database  man¬ 
agement  system  (DBMS)  needs  to  support:  valid  time,  transaction  time,  and  user-defined  time 
(Snodgrass  &  Ahn  1985,  SnodgTass  &  Ahn  1986].  Valid  time  concerns  modeling  time-varying  real¬ 
ity.  The  valid  time  of,  say,  an  event  is  the  clock  time  when  the  event  occurred  in  the  real  world, 
independent  of  the  recording  of  that  event  in  some  database.  Transaction  time ,  on  the  other  hand, 
concerns  the  storage  of  information  in  the  database.  The  transaction  time  of  an  event  is  the  trans¬ 
action  number  (an  integer)  of  the  transaction  that  stored  the  information  about  the  event  in  the 
database.  User-defined  time  is  an  uninterpreted  domain  for  which  the  DBMS  supports  the  opera¬ 
tions  of  input,  output,  and  perhaps  comparison.  As  its  name  implies,  the  semantics  of  user-defined 
time  is  provided  by  the  user  or  application  program.  These  three  types  of  time  are  orthogonal  in 
the  support  required  of  the  DBMS. 

In  these  same  papers,  we  defined  four  classes  of  relations  depending  on  their  support  for  valid 
time  and  transaction  time:  snapshot  relations,  rollback  relations,  historical  relations,  and  temporal 
relations.  User-defined  time,  unlike  valid  time  and  transaction  time,  is  already  supported  by  the 
relational  algebra,  in  that  it  is  simply  another  domain,  such  as  integer  or  character  string,  provided 
by  the  DBMS  [Bontempo  1983,  Overmyer  &  Stonebraker  1982,  Tandem  1983].  Snapshot  relations 
support  neither  valid  time  nor  transaction  time.  They  model  an  enterprise  at  one  particular  point 
in  time.  As  a  snapshot  relation  is  changed  to  reflect  changes  in  the  enterprise  being  modeled, 
past  states  of  the  relation,  representing  past  states  of  the  enterprise,  are  discarded.  A  snapshot 
relation  consists  of  a  set  of  tuples  with  the  same  set  of  attributes,  and  is  usually  represented  as  a 
two-dimensional  table  with  attributes  as  columns  and  tuples  as  rows,  as  shown  in  Figure  1.  Note 
that  snapshot  relations  are  exactly  those  relations  supported  by  the  relational  algebra.  Hence,  for 
clarity,  we  will  refer  to  the  relational  algebra  hereafter  as  the  snapshot  algebra.  Rollback  relations 
support  transaction  time  but  do  not  support  valid  time.  They  may  be  represented  as  a  sequence 
of  snapshot  states  indexed  by  transaction  time,  as  shown  in  Figure  2.  (Here,  the  last  transaction 
deleted  one  tuple  and  appended  another.)  Because  they  record  the  history  of  database  activity, 
rollback  relations  can  be  rolled  bank  to  one  of  their  past  snapshot  states  for  querying. 

Historical  relations  support  valid  time  but  do  not  support  transaction  time.  They  model  the 
history,  as  it  is  best  known,  of  an  enterprise.  When  an  historical  relation  is  changed,  however,  its 
past  state,  like  that  of  a  snapshot  relation,  is  discarded.  An  historical  relation  may  be  represented  as 
a  three-dimensional  solid,  as  shown  in  Figure  3.  Because  they  record  the  history  of  the  enterprise 
being  modeled,  historical  relations  support  historical  queries.  They  do  not,  however,  support 


Figure  1:  Snapshot  Relation 
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Figure  2:  Rollback  Relation 
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Figure  3:  Historical  Relation 


Figure  4:  Temporal  Relation 


rollback  operations.  Temporal  relations  support  both  valid  time  and  transaction  time.  They  may 
be  represented  as  a  sequence  of  historical  states  indexed  by  transaction  time,  as  shown  in  Figure  4. 
Because  they  record  both  the  history  of  the  enterprise  being  modeled  and  the  history  of  database 
activities,  temporal  relations  support  both  historical  queries  and  rollback  operations. 

Data  models  that  support  these  four  classes  of  relations  have  several  important  properties. 
First,  a  relation’s  scheme  can  no  longer  be  defined  in  terms  of  the  relation’s  attributes  alone;  it 
must  also  include  the  relation’s  class  (i.e.,  snapshot,  rollback,  historical,  or  temporal).  Second, 
rollback  and  temporal  relations,  unlike  snapshot  and  historical  relations,  are  append-only  relations. 
Information,  once  added  to  a  rollback  or  temporal  relation,  cannot  be  deleted;  otherwise,  rollback 
operations  could  not  be  supported.  Third,  valid  time  and  transaction  time  are  orthogonal  aspects 
of  time.  A  relation  may  support  cither  valid  time  or  tran-action  time  without  supporting  both. 
Also,  the  time  when  an  enterprise  changes  (i.e.,  valid  time)  need  not  be,  and  usually  will  not  be, 
the  same  as  the  time  when  the  database  is  updated  (i.e.,  transaction  time)  to  reflect  that  change. 
Finally,  the  same  measures  of  time  need  not  be  used  for  valid  and  transaction  time.  For  example,  a 


temporal  relation  will  have  a  variable  granularity,  which  changes  with  each  update,  for  transaction 
time  but  could  have  a  fixed  granularity  (e.g.,  second)  for  valid  time. 


Fortunately,  since  valid  time  and  transaction  time  are  orthogonal,  they  may  be  studied  in 
isolation.  There  have  already  been  several  proposals  for  adding  valid  time  to  the  snapshot  algebra 
[Ben-Zvi  1982,  Clifford  &  Croker  1987,  Gadia  1984,  Gadia  1986,  Jones  et  al.  1979,  Lorentzos  & 
Johnson  1987,  McKenzie  &  Snodgrass  1987B,  Navathe  &  Ahmed  1987,  Tansel  1986,  Yeung  1986], 
so  we  will  not  consider  valid  time  in  detail.  We  focus  here  on  extensions  to  support  transaction 
time. 

In  a  previous  paper  [McKenzie  &  Snodgrass  1987 A]  we  discussed  extensions  to  the  snapshot 
algebra  to  enable  it  to  handle  one  aspect  of  transaction  time:  evolution  of  a  database’s  contents. 
To  handle  evolution  of  the  contents  of  a  database  containing  both  snapshot  and  rollback  relations, 
we  defined  a  relation  to  be  a  sequence  of  snapshot  states,  ordered  by  transaction  number.  Snapshot 
relations  were  modeled  as  single-element  sequences  while  rollback  relations  were  modeled  as  multi¬ 
element,  append-only  sequences.  We  also  defined  a  database  to  be  an  ordered  pair  whose  first 
component  was  a  function  from  identifiers  (i.e.,  relation  names)  to  relations  and  whose  second 
component  was  the  transaction  number  of  the  most  recently  committed  transaction  on  the  database. 
We  then  augmented  the  algebra  with  a  rollback  operator  to  make  past -states  of  rollback  relations 
available  in  the  algebra  and  encapsulated  this  extended  algebra  in  a  language  of  commands  for 
database  update.  Finally,  we  showed  that  the  same  approach  could  be  used  to  extend  an  arbitrary 
historical  algebra  (i.e.,  an  algebra  supporting  valid  time)  to  handle  evolution  of  the  contents  of  a 
database  containing  both  historical  and  temporal  relations. 

We  now  want  to  extend  the  relational  algebra  to  handle  the  other  aspect  of  transaction  time: 
evolution  of  a  database’s  scheme.  Scheme  evolution  is  associated  solely  with  transaction  time, 
since  it  defines  how  reality  is  modeled  by  the  database.  For  example,  a  person’s  marital  status  is 
a  (time- varying)  aspect  of  reality,  but  the  decision  whether  to  record  marital  status,  encoded  in 
the  scheme,  is  a  (time- varying)  aspect  of  the  database.  Hence,  we  add  the  scheme  to  the  domain 
of  database  states.  The  scheme  and  the  contents  of  the  database  combine  to  define  the  database’s 
state. 


Adding  the  database’s  scheme  to  the  domain  of  database  states  requires  two  key  changes  to 
our  earlier  proposal.  First,  we  define  a  relation’s  scheme  to  be  a  pair  consisting  of  its  class  and  a 
function,  which  we  refer  to  hereafter  as  the  relation’s  signature,  that  maps  the  relation’s  attribute 
names  onto  their  value  domains.  (If  the  identification  of  primary  keys  is  desirable,  this  would  also 
properly  go  into  the  signature.)  Second,  we  augment  a  relation,  defined  in  our  earlier  paper  as 
a  single  sequence  of  states,  with  two  other  components:  a  sequence  of  classes  and  a  sequence  of 
signatures,  both  of  which  are  also  ordered  by  transaction  number.  A  relation’s  class  and  signature, 
as  well  as  its  state,  are  now  allowed  to  change  over  time.  We  retain  our  earlier  definition  of  a 
database  as  an  ordered  pair  whose  first  component  is  a  function  from  identifiers  to  relations  and 
whose  second  component  is  the  transaction  number  of  the  most  recently  committed  transaction  on 
the  database. 

To  express  scheme  evolution,  we  replace  the  modify jstate  command,  introduced  in  our  pre¬ 
vious  paper,  with  a  modify  .relation  command  that  alters  the  class  and  signature,  as  well  as 
the  state,  of  relations.  We  also  extend  the  define_ralation  command,  introduced  in  our  previ- 
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ous  paper,  to  handle  class  and  signature  and  we  define  the  new  commands  delete_relation  and 
rename  .relation.  The  delete_relation  is  the  counterpart  of  the  def  ine_relation  command. 
It  either  physically  or  logically  deletes  from  the  database  the  current  class,  signature,  and  state  of  a 
relation,  depending  on  the  relation’s  class  when  the  command  is  executed.  The  rename  .relation 
command  binds  the  current  class,  signature,  and  state  of  a  relation  to  a  new  identifier.  We  assume 
that  these  commands  execute  in  the  context  of  a  single,  previously  created  database.  Hence,  no 
commands  are  necessary  to  create  or  delete  the  database.  Since  we  are  considering  modeling  trans¬ 
action  time  from  a.  functional,  rather  than  a  performance,  viewpoint,  commands  affecting  access 
methods,  storage  mechanisms,  or  index  maintenance  are  also  not  relevant. 

Allowing  a  database’s  scheme  to  change  increases  the  complexity  of  our  language.  If  we 
allow  the  database’s  scheme  to  change,  an  algebraic  expression  that  is  semantically  correct  for  the 
database’s  scheme  when  one  command  executes  may  not  be  semantically  correct  for  the  database’s 
scheme  when  another  command  executes.  We  now  need  a  mechanism  for  identifying  semantically 
incorrect  algebraic  expressions  relative  to  the  database’s  scheme  when  each  command  executes  and 
a  way  of  ensuring  that  the  scheme  and  contents  of  the  database  state  resulting  from  the  command’s 
execution  are  compatible.  To  identify  semantically  incorrect  expressions,  we  introduce  a  semantic 
type  system  and  augment  all  commands  to  do  type-checking. 

Finally,  we  encapsulate  commands  within  a  system  of  transactions  to  provide  for  both  single¬ 
command  and  multiple-command  transactions.  A  multiple-command  transaction,  like  a  single¬ 
command  transaction,  is  treated  as  an  atomic  update  operation,  whether  it  changes  one  relation 
or  several  relations. 

Summarizing  these  changes,  we  add 

•  the  scheme  (i.e.,  class  and  signature)  to  the  formal  definition  of  database  state  and  to  the 
def  ine_relation  command, 

•  a  modif y_relation  command  to  handle  changes  in  both  the  scheme  and  contents  of  relations, 

•  delete_relation  and  rename_relation  commands, 

•  a  semantic  type  system  to  identify  semantically  incorrect  algebraic  expressions  and  enforce 
consistency  constraints  between  the  scheme  and  contents  of  the  database, 

•  augmented  commands  that  do  type-checking,  and 

•  a  system  of  transactions  to  provide  for  single-command  and  multiple-command  transactions. 

The  result  is  an  algebraic  language  that  supports  both  aspects  of  transaction  time:  evolution  of 
a  database’s  contents  and  evolution  of  its  scheme.  This  approach  applies  without  change  to  all 
historical  algebras  supporting  valid  time,  yielding  an  algebraic  language  for  the  query  and  update 
of  temporal  databases. 

This  language  was  designed  to  satisfy  several  other  objectives  as  well.  First,  the  language 
subsumes  the  expressive  power  of  the  snapshot  algebra.  For  every  expression  in  the  snapshot 
algebra,  there  is  an  equivalent  expression  in  our  language.  Second,  the  language  ensures  that  all 
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data  stored  in  a  relation  when  its  class  was  either  rollback  or  temporal  are  retained  permanently 
and  are  accessible  via  a  rollback  operator,  even  after  the  relation  is  logically  deleted  from  the 
database.  Third,  commands  change  only  the  class,  signature,  and  state  of  relations  current  at  the 
start  of  a  transaction.  Past  data  that  are  retained  to  support  rollback  operations,  once  saved, 
are  never  changed.  Hence,  the  language  accommodates  implementations  that  use  write-once-read- 
many  (WORM)  optical  disk  to  store  non-current  class,  signature,  and  state  information. 

In  defining  the  semantics  of  commands  and  algebraic  operators,  we  have  favored  simplicity 
of  semantics  at  the  expense  of  efficient  direct  implementation.  The  language  would  be  inefficient, 
in  terms  of  storage  space  and  execution  time,  if  mapped  directly  into  an  implementation.  How¬ 
ever,  the  semantics  do  not  preclude  more  efficient  implementations  using  optimization  strategies 
for  both  storage  and  retrieval  of  information.  In  Section  4,  we  review  briefly  some  of  the  tech¬ 
niques  for  efficient  implementation,  compatible  with  our  semantics,  that  have  been  proposed  by 
others.  We  also,  without  loss  of  generality,  assume  that  transactions  are  executed  sequentially  in  a 
single-user  environment.  Our  approach  applies  equally  to  environments  that  permit  the  concurrent 
execution  of  transactions  as  long  as  their  concurrency  control  mechanisms  induce  a  serialization  of 
transactions. 

Our  language  for  supporting  the  above  extensions  will  be  the  topie  of  the  next  section.  Ad¬ 
ditional  aspects  of  the  rollback  operators  are  discussed  briefly  in  Section  3.  Section  4  will  review 
related  work,  compare  our  approach  with  those  of  others,  and  note  possible  future  work. 


2  The  Language 


In  this  section  we  provide  the  syntax  and  denotational  semantics  of  our  language  for  database 
query  and  update.  In  denotational  semantics,  a  language  is  described  by  assigning  to  each  lan¬ 
guage  construct  a  denotation  -  an  abstract  entity  that  models  its  meaning  [Gordon  1979,  Scott 
1976,  Stoy  1977,  Strachey  1966],  We  chose  denotational  semantics  to  define  our  language  because 
denotational  semantics  combines  a  powerful  descriptive  notation  with  rigorous  mathematical  the¬ 
ory  [Gordon  1979],  permitting  the  precise  definition  of  database  state.  First,  we  define  the  syntax 
of  the  language.  Then  we  define  the  language’s  semantic  domains  and  a  semantic  type  system  for 
expressions.  Finally,  we  define  the  semantic  functions  that  map  the  language  constructs  onto  their 
denotations. 


2.1  Syntax 

Our  language  has  three  basic  types  of  language  constructs:  programs,  commands,  and  expressions. 
A  program  is  a  sequence  of  one  or  more  transactions.  Both  single-command  and  multi-command 
transactions  are  allowed.  Commands  occur  within  transactions;  they  change  relations  (e.g.,  define 
a  relation,  modify  a  relation,  delete  a  relation).  Expressions  occur  within  commands  and  denote 
a  single  snapshot  or  historical  state.  We  represent  these  three  types  of  constructs  by  the  syntactic 
categories: 
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VTZOQ'R.AM.  Category  of  programs 

COMMAAfD  Category  of  commands 

SXVTZSSSIOM  Category  of  expressions 

We  use  Backus-Naur  Form  to  specify  here  the  syntax  of  programs,  commands,  and  expressions 
in  terms  of  their  immediate  constituents  (i.e.,  the  highest-level  constructs  that  make  up  programs, 
commands,  and  expressions).  The  complete  syntax  of  the  language,  including  definitions  of  the 
lower-level  constituents  such  as  identifiers  and  snapshot  states  is  given  elsewhere  [McKenzie  1988]. 


P  ::=  begin_transaction  C  commit_transaction 
]  begin.transaction  C  abort.transaction 

I  Pi:  Pi 

C  ::=  define_relation(7,  Z ,  M)  |  modify_relation(7,  Z' ,  M' ,  E ) 

|  delete_relation(7)  |  rename_relation(7i ,  I2 )  |  Cj ,  C2 

E  ::=  [snapshot,  M ,  5]  |  [historical,  M ,  77]  \  I 
I  E\  U  E2  j  -  E2  |  Ei  x  E2  |  *x  C^1)  I  opiE) 

I  Ei  0  E2  |  Ei  —  E2  |  E\  x  E2  |  ir x(E)  \  op(.E ) 

\pU,N)  |  pU.N) 

Z'  ::=  Z\* 

Z  ::=  snapshot  ]  rollback  |  historical  )  temporal 
M'  ::=  M  \  * 

M  ::=  (7i,i  :  I\,2*  •••■>  7j,i  r  7^2) 

where, 

C,  Ci,  and  C2  range  over  the  category  COMMANV\ 

E,  Ex,  and  E2  range  over  the  category  €XPTZ£SSIOJ<f ; 

F  ranges  over  the  category  T  of  boolean  expressions  of  elements  from  the  categories 
XVCMTFEISTZ  and  SUZlAfQ  (i.e.,  the  category  of  strings  in  an  alphabet), 
the  relational  operators,  and  the  logical  operators; 

H  ranges  over  the  category  H- STATE  of  alphanumeric  representations  of  historical 
states  in  an  arbitrary  historical  algebra; 

7  7j,  I2,  I11,  ■  ■  -i  7>i2  range  over  the  category  TD£A/TLFI£1Z  of  alphanumeric 
identifiers; 

M  ranges  over  the  category  SIQMATUV.E  of  alphanumeric  representations 
of  signatures; 
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N  ranges  over  the  category  AliMSHAL  of  decimal  .numerals; 

P,  Pi,  and  Pi  range  over  the  category  VROQUAM: 

S  ranges  over  the  category  S-STATE  of  alphanumeric  representations  of  snapshot 
states; 

X  ranges  over  the  category  PiTDEAPTZTTE'R.') ,  the  power  set  of  TD EJCTHFZEIZ ;  and 
Z  ranges  over  the  category  CLASS  of  character  strings  denoting  relation  classes. 


An  expression,  which  evaluates  to  either  a  snapshot  or  historical  state,  may  be  a  constant  (i.e., 
an  ordered  triple  consisting  of  a  relation  class,  signature,  and  state);  an  identifier  /,  representing 
the  current  state  of  the  relation  denoted  by  /;  or  an  algebraic  operator  on  either  one  or  two  other 
expressions.  The  allowable  operators  include  the  five  operators  that  serve  to  define  the  snapshot 
algebra  and  the  operators  that  serve  to  define  an  arbitrary  historical  algebra  [McKenzie  &  Snodgrass 
1987C].  Any  operator  in  a  given  historical  algebra  may  be  included  in  the  language  as  long  as 
expressions  involving  that  operator  evaluate  to  a  single  historical  state  in  the  algebra  Because 
historical  algebras  have  different  sets  of  operators,  we  show  here  only  the  historical  counterparts 
to  the  conventional  algebraic  operators,  simply  for  illustration.  Each  is  represented  as  op  to 
distinguish  it  from  its  snapshot  algebra  counterpart  op.  We  also  have  included  two  additional 
operators,  a  rollback  operator  p  and  its  historical  counterpart  p.  The  rollback  operator  p  takes  two 
arguments,  an  identifier  I  and  a  transaction  number  N,  and  retrieves  from  the  relation  denoted 
by  I  the  snapshot  state  current  at  the  time  of  transaction  N.  Similarly,  the  rollback  operator  p 
retrieves  from  the  relation  denoted  by  I  the  historical  state  current  at  the  time  of  transaction  N. 

EXAMPLES.  The  following  are  two  examples  of  syntactically  correct  expressions  in  the  language. 
The  first  is  a  constant  and  the  second  is  an  expression  involving  both  a  rollback  operator  and  a 
constant.  Their  semantics  will  be  specified  in  Sections  2.3  and  2.4.  Because  the  historical  algebras 
all  define  historical  relations  differently,  we  show  in  this  paper  only  examples  involving  snapshot 
and  rollback  relations.  Each  example,  however,  has,  for  a  given  arbitrary  historical  algebra,  an 
analogue  involving  historical  and  temporal  relations. 


[snapshot,  (sname: string,  class : string) ,  (sname : "Phil" ,  class : "junior") , 

(sna^ie :  "Linda" ,  class :  "senior")  , 
(sname : "Ralph" ,  class : "senior")] 

^sname t^CRl ,  4))  x  [snapshot,  (course: string) ,  (course: "English")] 


Note  that  the  alphanumeric  representation  of  a  signature  includes  both  the  names  of  attributes 
and  the  names  of  the  attributes’  value  domains.  □ 

There  are  four  commands  in  the  language.  We  present  here  a  brief  description  of  each  com-  | 

mand,  with  some  examples.  The  semantics  of  commands  will  be  defined  formally  in  Section  2.5. 

The  define  .relation  command  binds  a  class,  a  signature,  and  an  empty  relation  state  to  an 
identifier  /. 

I 
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EXAMPLE. 


def  ine_relation(Rl ,  snapshot,  (sname:  string,  class  -.string) ) 


Here,  the  identifier  R1  is  defined  to  denote  a  snapshot  relation  with  two  attributes,  sname  and 
class.  The  contents  of  the  relation  is,  by  default,  the  empty  set.  □ 

The  modify_relation  command  may  change  the  current  class,  signature,  or  state  of  a  rela¬ 
tion.  Command  parameters  specify  the  new  class,  signature,  and  state.  The  special  symbol 
represents,  depending  on  context,  either  the  current  class  or  the  current  signature  of  a  relation.  It 
may  appear  as  a  parameter  in  a  modif yjrelation  command  to  indicate  that  a  relation’s  new  class 
(or  signature)  is  simply  the  relation’s  current  class  (signature),  unchanged. 


EXAMPLES. 


modify_relation(Rl ,  *,  *,  [snapshot,  (sname  .‘string,  class  .-string}  , 

(sname :  "Phil11 ,  class :  "junior")  , 

(sname: "Linda",  class : "senior") , 

(sname: "Ralph" ,  class : "senior")] ) 


modify_relation(Rl ,  *,  (sname: string,  course : string) , 

7Tsname(Rl)x  [snapshot,  (course : string) , 
(course: "English")] ) 


modif y_relation(Rl ,  rollback,  *,  Rl) 


T;'c‘  first  command  changes  the  state  of  the  relation  denoted  by  Rl  but  leaves  the  relation’s  class 
and  signature  unchanged.  The  second  command  changes  the  relation’s  signature  and  state,  but 
not  its  class.  The  third  command  changes  only  the  relation’s  class,  as  the  expression  Rl  evaluates 
to  the  current  state  of  the  relation.  □ 

The  deletejrelation  command  either  physically  or  logically  deletes  a  relation’s  current 
class,  signature,  and  state  depending  on  the  relation’s  class  when  the  command  is  executed.  The 
rename_relation  command  renames  a  relation  by  binding  its  current  class,  signature,  and  state 
to  a  new  identifier. 


EXAMPLES. 

delete_relation(Rl) 
rename  .relation (R2,  Rl) 
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Here  we  first  delete  the  relation  denoted  by  R1  an  1  chen  rename  the  relation  denoted  by  R2  as  Rl.  □ 

Programs  in  our  language  contain  two  types  of  transactions,  committed  transactions  ar  ; 
aborted  transactions.  Committed  transactions  are  transactions,  which  the  user  initiates,  that 
eventually  commit.  Aborted  transactions  are  transactions,  whic  the  user  initiates,  that  for  some 
reason,  dictated  either  by  the  user  or  by  the  system,  abort  rather  -han  commit.  The  semantics  of 
programs  will  be  defined  formally  in  Section  2.6. 


2.2  Semantic  Domains 

In  our  language,  a  program  denotes  the  database  resulting  from  the  execution  of  one  or  more 
transactions,  in  order,  on  an  empty  database.  By  defining  the  database  that  results  from  the 
execution  of  an  arbitrary  sequence  of  transactions,  we  specify  the  semantics  of  that  transaction 
sequence,  and  hence  the  semantics  of  ‘he  language.  In  this  section,  we  will  define  formally  the  flat 
domain  (i.e,  a  domain  with  a  trivial  partial  ordering  [Schmidt  1986])  of  databases;  la^r  sections 
will  provide  the  connection  between  the  syntactic  category  of  programs  and  the  semantic  domain 
of  databases.  All  domains  introduced  are  flat  domains  and  the  notation-^-  •  •}  is  used  to  represent 
flat  domains. 

Assume  that  we  are  given  the  domain  V  =  { D\ ,  ,  Vy },  where  each  domain  Vj,  1  <  j <  y, 
is  an  arbitrary,  non-empty,  finite  or  denumerable  set.  Then,  we  can  define  the  following  semantic 
domains  for  our  language. 


TUAN'S  ACTIO  AT  NUMBER  =  {0,  1,  ...} 


A  transaction  number  is  a  non-negative  integer  that  identifies  a  transaction  that  changes  the 
database.  The  transaction  number  assigned  to  a  transaction  can  be  viewed  as  that  transaction’s 
time-stamp. 


RELATION  CC ASS  —  {undefined,  snapshot,  rollback,  historical,  temporal) 


A  relation  is  either  undefined  or  defined  to  be  a  snapshot,  rollback,  historical,  or  temporal 
relation. 


RELATION  SIGNATURE  =  TDENTITIER  -»  !  V  +  {unbound}] 

where  the  notation  “+”  on  domains  means  the  disjoint  union  of  domains.  A  relation’s  signature 
is  a  function  that  maps  identifiers  either  onto  a  domain  D j,  1  <  j  <  y  or  onto  unbound.  If  a 
signature  maps  an  identifier  onto  unbound,  then  the  identifier  is  unbound  in  that  signature  (i.e., 
it  is  associated  with  no  domain).  If,  however,  a  signature  maps  an  identifier  onto  a  domain,  then 
that  mapping  defines  an  attribute. 
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SAfAVSHOT  STATS  =  Domain  of  all  semantically  correct  snapshot  states  (sets  of  n-tuples), 
as  defined  in  the  snapshot  algebra  [Maier  1983],  for  elements  of  the  domain  HS CATIOAf 
SIGAfATUHS  and  the  domain  {V\  +  •  ■  ■  +  T>v},  where  0  is  the  empty  snapshot  state. 
Hence,  a  snapshot  state  so  n  a  relation  signature  m  is  a  finite  set  of  mappings  from 
{/  |  m(J)  ^  unbound}  to  V.  with  the  restriction  that  for  each  mapping  t  €  s,  t(I )  6  m(7). 

7HSTOTZICAC  STATS  —  Domain  of  all  semantically  correct  historical  states  as  defined  in  an 
arbitrary  historical  algebra  (e.g.,  as  defined  in  [Ben-Zvi  1982,  Clifford  k  Croker  1987, 
Gadia  1984,  Gadia  1986,  Jones  et  al.  1979,  Lorentzos  &  Johnson  1987,  McKenzie  & 
Snodgrass  1987B,  Navathe  k  Ahmed  1987,  Tansel  1986,  Yeung  1986]). 


HSCATLOAf  =  [  US  CATIOAf  CLASS  x  THAAfS  ACTIO  Al  AfUMBSn  x 

[  THAAfS  ACTIO Af  AfUMBSH  +  {-}  ]  ]+  x 
[  ns  CATIOAf  SIGAfATUHS  x  THAAfS  ACTIO  Af  AfUM  BSn  ]  *  x 
[  ( SAfAVSHOT  STATS  x  THAAfS  A  CTIOAf  AfUMBSH )  + 

[  mSTOHICAC  STATS  x  THAAfS ACTIO Af  AfUMBSH)  ]* 


where  the  special  element  stands  for  the  present  time.  A  relation  is  thus  an  ordered  triple 
consisting  of 


•  a  sequence  of  (relation  class,  transaction  number,  transaction  number  or  triples, 

•  a  sequence  of  (relation  signature,  transaction  number)  pairs,  and 

•  a  sequence  of  (relation  state,  transaction  number)  pairs. 


Relations  are  dynamic  objects  whose  class,  signature,  and  state  are  all  allowed  to  change  over 
time.  For  example,  a  relation  defined  initially  as  a  snapshot  relation  could  be  modified  to  be  an 
historical,  rollback,  or  temporal  relation.  Later,  the  relation  could  be  modified  to  be  a  snapshot 
relation  once  again.  Every  relation  always  has  at  least  one  element  in  its  class  sequence,  the  last 
element  recording  the  relation’s  current  class  (i.e.,  undefined,  snapshot,  rollback,  or  temporad). 
Any  other  elements  in  the  sequence  record  intervals  when  the  relation’s  class  was  either  rollback 
or  temporal. 

A  relation’s  signature  (state)  sequence  will  be  empty  only  if  the  relation  is  currently  undefined 
and  it  was  never  a  rollback  or  temporal  relation.  If  a  relation  is  currently  other  than  undefined,  there 
is  at  least  one  element  in  its  signature  (state)  sequence,  the  last  element  recording  the  relation’s 
current  signature  (state).  Any  other  elements  in  the  sequence  record  the  signature  (state)  of  the 
relation  when  its  class  was  either  rollback  or  temporal. 

The  transaction-number  components  of  all  elements,  but  the  last  element,  in  a  relation’s 
class  sequence  can  be  viewed  as  time-stamps  defining  a  fixed,  closed  interval  during  which  the 
element’s  class  component  was  the  relation’s  class.  In  contrast,  the  third  component  of  the  last 


12 


element  in  the  sequence  is  always  it  is  used  to  define  an  interval  of  dynamic  length  that 
always  extends  to  the  present.  The  transaction-number  component  of  each  element  in  a  relation’s 
signature  (state)  sequence  can  be  viewed  as  a  time-stamp  indicating  when  the  element’s  signature 
(state)  was  entered  into  the  database  and  became  the  relation’s  current  signature  (state).  Since  we 
assume  that  database  changes  occur  sequentially,  the  transaction-number  components  of  a  signature 
(state)  sequence,  while  not  necessarily  consecutive,  will  be  nevertheless  strictly  increasing.  Thus, 
we  can  interpolate  on  the  transaction-number  component  of  elements  in  a  relation’s  signature 
(state)  sequence  to  determine  the  signature  (state)  of  the  relation  at  any  time  its  class  was  either 
rollback  or  temporal. 

EXAMPLE.  The  following  is  a  sample  relation.  For  notational  convenience  in  this  and  later 
examples,  we  show  only  the  attribute  portion  of  a  signature  (i.e.,  the  partial  function  from  attribute 
names  to  value  domains).  Each  signature  maps  all  identifiers  not  shown  onto  unbound.  Also  for 
notational  convenience,  we  assume  the  natural  mapping  from  attribute  names  onto  attribute  values 
for  each  tuple  (e.g.,  (enama  — »  “Phil”,  ssn  — ♦  250861414)). 


class 

signature 

State 

((rollback,  2,  6), 

(((sname  — ►  string, 
ssn  — ►  integer),  2), 

irra 

({(“Phil”,  250861414), 

(“Linda",  147894290), 
(“Ralph”,  459326889)},  4), 

((sname  -»  string/ 
class  — *  string),  5), 

({(“Phil”,  “junior”), 

(“Linda”,  “senior”), 

(“Ralph”,  “senior”)},  5), 

(snapshot,  8,  -) 

> 

((ssn-*  integer, 
class  -*•  string),  8) 

> 

({(250861414,  “junior”), 
(147894290,  “senior”), 
(459326889,  “senior”)},  8)  ) 

The  relation  shown  here  was  defined  to  be  a  rollback  relation  by  transaction  2  and  remained  a 
rollback  relation  through  transaction  6.  While  the  relation  was  a  rollback  relation,  all  changes  to 
its  signature  and  state  were  recorded;  its  state  was  changed  by  transaction  4  and  both  its  signature 
and  state  were  changed  by  transaction  5.  Transaction  7  redefined  the  relation’s  class  and  the 
relation  was  last  updated  as  a  snapshot  relation  by  transaction  8.  Only  when  a  relation’s  current 
class  is  either  rollback  or  temporal  is  the  relation  treated  as  an  append-only  relation.  In  all  other 
cases,  updates  cause  outdated  information  to  be  discarded.  Hence,  the  lack  of  information  about 
the  relation’s  class,  signature,  and  state  before  transaction  2  and  at  transaction  7  implies  that  the 
relation  was  either  undefined  or  a  snapshot  or  historical  relation  at  those  times.  Note  that  this 
relation  can  be  rolled  back  only  to  transactions  2  through  6.  Also  note  that  the  last  element  in  the 
class  sequence  defines  the  relation  to  be  a  snapshot  relation  from  transaction  8  to  the  present.  □ 


VATABASS  STALL  =  TDLNTLTISTl  -  TLSCATIOAf 
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A  database  state  is  a  function  that  maps  each  identifier  onto  a  relation.  If  an  identi¬ 
fier  I  is  mapped  onto  a  relation  whose  current  class  is  undefined,  then  I  denotes  an  unde¬ 
fined  relation.  In  the  empty  database  state,  all  identifiers  map  onto  undefined  relations  (i.e., 
(  ((undefined,  0,  -)),  (  ),  (  )  )). 


VATABASE  =  VATABASE  STATE  x  TRAMS  ACTION  MUM  BETZ 


A  database  is  an  ordered  pair  consisting  of  a  database  state  and  the  transaction  number 
assigned  to  the  most  recently  committed  transaction  on  the  database  state  (i.e.,  the  last  transaction 
to  cause  a  change  to  the  database  state). 


2.3  A  Semantic  Type  System  for  Expressions 

Before  specifying  the  semantics  of  the  expressions  defined  syntactically  in  Section  2.1,  we  introduce 
a  semantic  type  system  for  expressions.  All  syntactically  correct  expressions  in  our  language  are 
not  necessarily  semantically  correct.  An  expression  is  semantically  correct,  with  respect  to  a 
database  state  and  a  command,  only  if  its  evaluation  on  the  database  state  during  the  command’s 
execution  produces  either  a  snapshot  or  an  historical  state.  Also,  if  the  expression  contains  a 
rollback  operator,  it  must  be  consistent  with  the  class  and  signature  of  the  relation  being  rolled 
backed  at  the  time  of  the  transaction  to  which  the  relation  is  rolled  back.  Because  the  class 
and  signature,  as  well  as  the  state,  of  a  relation  are  allowed  to  change  over  time,  the  semantic 
correctness  of  expressions  also  can  vary  over  time.  Hence,  expressions  that  are  semantically  correct 
on  a  database  state  when  one  command  is  executed  may  not  be  semantically  correct  on  the  same 
database  state  when  a  subsequent  command  is  executed  (although  the  correctness  of  rollback 
operations  to  existing  states  will  be  unaffected  by  subsequent  commands). 

The  semantic  type  system  defined  here  allows  us  to  do  expression  type-checking  independent 
of  expression  evaluation.  In  Section  2.4,  where  we  define  the  semantics  of  expressions,  we  will 
use  the  type  system  to  restrict  evaluation  of  expressions  to  semantically  correct  expressions  only. 
Hence,  any  future  implementation  of  the  language  can  avoid  the  unnecessary  cost  associated  with 
attempted  evaluation  of  semantically  incorrect  expressions.  The  type  system  will  also  be  used  to 
define  the  semantics  of  commands  so  that  commands  whose  execution  would  result  in  an  incom¬ 
patibility  among  a  relation’s  class,  signature,  and  state  will  never  be  executed.  Also,  separation  of 
semantic  type-checking  and  evaluation  of  expressions  simplifies  the  formal  definitions  of  the  seman¬ 
tics  of  both  expressions  and  commands.  Note  that  while  semantic  type-checking  and  evaluation  of 
some  expressions  (i.e.,  those  expressions  involving  only  constant  expressions  and  rollback  operators 
that  roll  back  a  relation  prior  to  the  query  analysis  time)  can  be  done  when  a  query  is  analyzed, 
most  semantic  type-checking  and  expression  evaluation  will  have  to  be  done  when  the  query  is 
executed. 

Semantically  correct  expressions  in  our  language  evaluate  to  either  a  single  snapshot  state 
or  a  single  historical  state.  We  define  a  snapshot  state’s  type  to  be  an  ordered  pair  whose  first 
component  is  snapshot  and  whose  second  component  is  the  state’s  signature.  Similarly,  we  define 
an  historical  state’s  type  to  be  an  ordered  pair  whose  first  component  is  historical  and  whose 
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second  component  is  the  state’s  signature.  A  semantically  correct  expression’s  type  is  therefore 
the  class  and  signature  of  the  relation  state  resulting  from  the  expression’s  evaluation  and  two 
expressions  are  said  to  be  of  the  same  type  if  and  only  if  they  evaluate  to  either  snapshot  or 
historical  states  on  the  attributes  of  the  same  signature. 

We  use  the  semantic  function  T  to  specify  an  expression’s  type.  A  semantic  function  is  simply 
a  function  that  maps  a  language  construct  onto  its  denotation  or  meaning.  T  defines  an  expression 
as  a  function  that  maps  a  database  state  and  a  transaction  number  onto  either  an  ordered  pair 
or  typeerror,  depending  on  whether  the  expression  is  a  semantically  correct  expression  on  the 
database  state  when  a  command  in  the  transaction  assigned  the  transaction  number  is  executed. 
The  ordered  pair  will  have  as  its  first  component  either  snapshot  or  historical  and  as  its  second 
component  the  signature  of  the  relation  state  that  the  expression  represents.  Hence,  T  defines  the 
type  denotation  of  expressions  in  our  language. 


T  :  EXPRESSION  -  [  [  VAT  ABASE  STATE  x  TRANSACTION  NUMBER) 

[[{snapshot,  historical}  X 
RELATION  SIGNATURE  ]  +  {typeerror}  ]  ] 


The  result  of  type-checking  a  syntactically  correct  expression  is  the  class  and  signature  of  the 
relation  state  that  the  expression  represents  if  the  expression  is  semantically  correct  and  an  error 
if  the  expression  is  semantically  incorrect.  An  expression’s  type  may  depend  on  a  database  state’s 
contents.  The  type  of  an  expression  involving  a  rollback  operator  also  depends  on  the  transaction 
number  of  the  transaction  in  which  the  command  containing  the  expression  occurs.  Hence,  a 
database  state  and  transaction  number  together  define  the  environment  in  which  type-checking  is 
performed. 

Before  defining  the  semantic  function  T,  we  describe  informally  several  auxiliary  functions 
used  in  its  definition.  Formal  definitions  for  FINDTYPE  and  FINDSIGNATURE  appear 
elsewhere  [McKenzie  1988].  Formal  definitions  for  the  other  functions  are  either  straightforward 
or  cumbersome  and  therefore  not  presented. 

FINDCLASS  maps  a  relation  onto  the  class  component  of  the  element  in  the  relation’s  class 
sequence  whose  first  transaction- number  component  is  less  than  or  equal  to  a  given  integer 
and  whose  second  transaction-number  component  is  greater  than  or  equal  to  the  integer.  If 
no  such  element  exists  in  the  sequence,  then  FINDCLASS  returns  error. 

FINDSIGNATURE  maps  a  relation  onto  the  signature  component  of  the  element  in  the  re¬ 
lation’s  signature  sequence  having  the  largest  transaction-number  component  less  than  or 
equal  to  a  given  integer,  if  FINDCLASS  does  not  return  an  error  for  the  same  integer.  If 
FINDCLASS  returns  an  error  or  no  such  element  exists  in  the  sequence,  then  FINDSIG¬ 
NATURE  returns  error. 

LASTCLASS  maps  a  relation  onto  the  class  component  of  the  last  element  in  the  relation’s  class 
sequence. 


15 


LASTSIGNATURE  maps  a  relation  onto  the  signature  component  of  the  last  element  in  the 
relation’s  signature  sequence.  If  the  relation’s  signature  sequence  is  empty,  LASTSIGNA¬ 
TURE  returns  error. 

H  is  a  semantic  function  that  maps  each  alphanumeric  representation  of  an  historical  state  in  the 
syntactic  category  ‘H-STATE  onto  its  corresponding  historical  state  in  the  semantic  domain 
HISTORICAL  STATE.  The  definition  of  H  depends  on  the  historical  algebra  used,  as  each 
historical  algebra  requires  a  different  version  of  the  function. 

M  is  a  semantic  function  that  maps  each  alphanumeric  representation  of  a  relational  signature 
in  the  syntactic  category  SIGNATURE  onto  its  corresponding  relational  signature  in  the 
semantic  domain  RE  CATIONS  SIGNATURE. 

N  is  a  semantic  function  that  maps  the  syntactic  category  NUMERAL  of  decimal  numerals  into 
the  semantic  domain  TRANSACTION!  NUMBER. 

S  is  a  semantic  function  that  maps  each  alphanumeric  representation  of  a  snapshot  state  in  the 
syntactic  category  S-STATZ  onto  its  corresponding  snapshot  state  in  the  semantic  domain 
SNAPSHOT  STATE. 

Z  is  a  semantic  function  that  maps  each  character  string  in  the  syntactic  category  CLASS  onto 
the  relation  class  that  it  denotes  in  the  semantic  domain  RELATION  CLASS. 

VALIDF  is  a  boolean  function  that  determines  whether  a  boolean  expression  F  is  a  valid  boolean 
expression  for  the  selection  operator  a  and  a'  given  signature. 

VALIDH  is  a  boolean  function  that  determines  whether  an  historical  state  is  a  valid  historical 
state  on  a  given  signature.  The  definition  of  VALIDH,  like  that  of  H,  depends  on  the 
historical  algebra  used. 

VALIDS  is  a  boolean  function  that  determines  whether  a  snapshot  state  is  a  valid  snapshot  state 
on  a  given  signature. 

VALIDX  is  a  boolean  function  that  determines  whether  each  identifier  in  a  set  of  identifiers  X  is 
mapped  onto  a  domain  in  a  given  signature. 

We  now  define  formally  the  semantic  function  T  for  each  kind  of  expression  allowed  in  our 

language.  For  this  and  later  definitions  of  semantic  functions,  let 

d  range  over  the  domain  DATABASE  STATE , 

m,  mlt  and  m2  range  over  the  domain  RELATION  SIGNATURE ,  and 

n  range  over  the  domain  TRANSACTION  NUMBER. 


Tf [snapshot ,  M,  5] J(d,  n)  =  if  (M[M]  ^  error  A  S([SJ  ^  error 

A  VALIDS  (M[Af  1,  SI5J)) 
then  (snapshot,  M[AfJ) 

else  TYPEERROR 

If  a  snapshot  constant  represents  a  snapshot  state  on  a  signature,  the  expression’s  type  is  the 
ordered  pair  whose  first  component  is  snapshot  and  whose  second  component  is  the  snapshot 
state’s  signature.  Otherwise,  evaluation  of  the  expression’s  type  results  in  an  error. 

EXAMPLE.  For  this  and  later  examples  in  Section  2,  assume  that  we  are  given  the  database 
(DS,  8)  where  the  database  state  DS  maps  the  identifier  R1  onto  the  relation  shown  in  the  example 
on  page  13. 

T|[snapshot,  (sname: string,  class : string)  ,  (sname : "Phil",  class junior" )  , 

(sname: "Linda" ,  class: "senior") , 
(sname: "Ralph" ,  class : "senior")] 
J(DS,9)  =  (snapshot,  (sname  — *  string,  class  — *  string)) 

Here  we  assume  that  type-checking  is  being  performed  as  part  of  transaction  9.  Note,  however,  that 
the  database  state  is  not  consulted  to  determine  the  constant  expression’s  type;  the  expression’s 
type  is  independent  of  the  database  state.  Actually,  the  only  expressions  whose  type  depends 
directly  on  the  database  state  are  identifiers  and  expressions  involving  the  rollback  operators.  □ 

Evaluation  of  a  snapshot  constant’s  type  produces  an  error  if  and  only  if  the  expression  does 
not  represent  a  snapshot  state  on  a  signature.  As  we  will  see  in  Section  2.4,  evaluation  of  a 
constant  expression’s  type  produces  an  error  under  exactly  the  same  conditions  that  evaluation  of 
the  expression  produces  an  error.  This  relationship  between  a  constant  expression’s  type  and  value 
is  both  a  necessary  and  sufficient  condition  to  ensure  that  the  evaluation  of  any  expression  will 
result  in  an  error  when  evaluation  of  the  expression’s  type  results  in  an  error. 
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T[IJ(d,  n) 


if  (LASTCLASS  (d(/))  =  snapshot 

V  LASTCLASS  (d(/))  =  rollback) 
then  (snapshot,  LASTSIGNATURE(d(/))) 
eLe  if  (LASTCLASS  ( d(I ))  =  historical 
v  LASTCLASS  ( d(7 ))  =  temporal) 
then  (historical,  LASTSIGNATURE(d(/))) 
else  TYPEERROR 


where  the  notation  d(I)  stands  for  the  relation  denoted  by  the  identifier  I  in  the  database  state  d. 
The  type  of  an  expression  I  is  the  ordered  pair  whose  first  component  is  snapshot  if  J’s  current 
class  is  either  snapshot  or  rollback  and  historical  if  its  current  class  is  either  historical  or  temporal. 
The  ordered  pair’s  second  component  is  always  /’s  current  signature.  An  error  occurs  if  the  relation 
is  currently  undefined. 


EXAMPLE. 

T[Rl|(DS,9)  =  (snapshot,  (ssn  -*  integer,  class  — *•  string)) 


□ 


TlEj  U  E2}(d,  n)  =  if  T|Ei](d,  n)  =  Tj^K^,  n)  =  (snapshot,  m) 
then  T|[.Ei](d,  n) 
else  TYPEERROR 

T {Ei  -  E2}{d,  n)  =  if  Tf-E^Kd,  n)  =  T|£2]|(<f,  n)  =  (snapshot,  m) 

then  T[f?i](d,  n) 
else  TYPEERROR 
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TfiTiX  E2](d,  n)  = 

if  (T[£i]](d,  n)  =  (snapshot,  mj)  A  Tj.E2](<i,  n)  =  (snapshot,  m2) 

A  V/,  /  e  TDEATTIFIFR.,  (mx(/)  =  unbound  v  m2(/)  =  unbound)) 
then  (snapshot,  {(/,  £>j)  |  1  <  j  <  y  A  ((/,  Z?j)  €  mj  V  (/,  2?y)  €  m2)} 

U  {(/,  unbound)  1 1  6  TDSMTITISnZ  A  (/,  unbound)  €  mi 
A(/,  unbound)  e  m2}) 

else  TYPEERROR 


T[irx  (£)]  (d,  n)  = 

if  (T[£](<i,  n)  =  (snapshot,  m)  A  VALIDX  (m,  X)) 
then  (snapshot,  {(/,  Dj)  J  /  €  X  A  1  <  j  <  y  A  (J,  2?^)  €  m} 

U  {(/,  unbound)  |  7  0  X  A  I  6  TD£MT£TI£1Z}) 

else  TYPEERROR 


TfaF(£)](<f,  n) 


if  (T(£J  (d,  n)  =  (snapshot,  to)  a  VALIDF  (to,  F )) 
then  T[FJ  (d,n) 

else  TYPEERROR 


The  type  of  an  expression  involving  one  of  the  five  basic  snapshot  operators  is  an  ordered  pair 
whose  first  component  is  snapshot  and  whose  second  component  is  the  signature  of  the  relation 
state  produced  when  the  expression  is  evaluated,  if  two  conditions  are  met.  The  first  component 
of  the  type  of  all  subexpressions  must  be  snapshot  and  the  second  component  of  the  type  of  all 
subexpressions  must  be  a  signature  satisfying  any  restrictions  placed  on  the  signatures  of  relation 
states  in  corresponding  expressions  in  the  snapshot  algebra.  For  example,  our  definitions  of  union 
and  difference  require  that  the  signatures  for  E i  and  £2  be  identical  while  our  definition  of  cartesian 
product  requires  that  the  attributes  defined  by  the  signatures  for  E\  and  £2  be  disjoint.  (Note 
that  we  cam  eliminate  this  last  restriction  and  effectively  allow  the  cartesian  product  of  snapshot 
states  on  arbitrary  signatures  through  the  introduction  of  a  simple  attribute  renaming  operator 
[Maier  1983]  into  the  language.)  If  either  condition  is  not  met,  evaluation  of  the  expression’s  type 
results  in  an  error. 
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T IpU.  iV)J  (d,  n)  =  if  NfjVJ  <  n  A  FINDTYPE  (d(I),  NffVj)  =  rollback 

then  (snapshot,  FINDSIGNATURE  (d(7),  N[Arj)) 

else  TYPEERROR 


A  rollback  expression’s  type  is  the  ordered  pair  whose  first  component  is  snapshot  and  whose  second 
component  is  the  signature  of  the  relation  denoted  by  7  when  transaction  N[7/J  was  processed, 
if  the  relation  was  a  rollback  relation  at  that  time.  Otherwise,  evaluation  of  the  expression’s  type 
results  in  an  error.  Because  we  assume  sequential  transaction  processing,  n  is  the  transaction 
number  of  the  one  active  transaction  and  all  transactions  with  a  transaction  number  less  than  n 
are  committed.  Hence,  we  allow  rollback  only  to  committed  transactions. 


EXAMPLES. 

T[p(Rl,  4)]](DS,9)  =  (snapshot,  (sname  — *  string,  ssn  -►  integer)) 

Tf7rSname(pOU,  4))J(DS,9)  =  (snapshot,  (sname  — ►  string)) 

T[7rSname  (pOU »  4))  x  [snapshot,  (course : string)  ,  (course :  "English")] 
KDS,?)  =;  (snapshot,  (sname  — »  string,  course  — ►  string)) 


□ 


The  semantic  function  T  for  expressions  involving  historical  operators  follows  directly.  The 
type  denotations  for  these  expressions  are  identical  to  those  for  expressions  involving  snapshot 
operators,  except  that  historical  and  temporal  are  substituted  for  snapshot  and  rollback, 
respectively. 


2.4  Expressions 


The  semantic  function  E  defines  the  denotation  of  expressions  in  our  language.  E  defines  an 
expression  as  a  function  that  maps  a  database  state  and  a  transaction  number  onto  either  a  snapshot 
state  (i.e.,  an  element  of  the  SMAVSKOT  STATE  semantic  domain),  an  historical  state  (i.e.,  an 
element  of  the  HISTORICAL  STATE  semantic  domain),  or  error. 


E  :  EXPRESSION  -  [[DATABASE  STATE  x  TRANSACTION  NUMBER)  — 

[SNAPSHOT  STATE  +  HISTORICAL  STATE  +  {error}]] 
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If  an  expression  is  a  semantically  correct  expression  on  a. database  state,  expression  evaluation  on 
the  database  state  produces  either  a  snapshot  state  or  an  historical  state.  Otherwise,  expression 
evaluation  produces  an  error.  The  environment  for  expression  evaluation,  a  database  state  and 
the  transaction  number  of  the  active  transaction,  is  the  same  as  that  for  expression  type-checking. 
Note  that  expression  evaluation  has  no  side-effect;  it  leaves  the  database  state  unchanged. 

Before  defining  the  semantic  function  E,  we  describe  informally  FINDSTATE  and  LAST- 
STATE,  two  additional  auxiliary  functions  used  in  E’s  definition.  Formal  definitions  appear 
elsewhere  [McKenzie  1988]. 

FINDSTATE  maps  a  relation  onto  the  state  component  of  the  element  in  the  relation’s  state 
sequence  having  the  largest  transaction-number  component  less  than  or  equal  to  a  given 
integer,  if  FENDCLASS  does  not  return  an  error  for  the  same  integer.  If  FINDCLASS 
returns  an  error  or  no  such  element  exists  in  the  sequence,  then  FINDSTATE  returns  error. 

LASTSTATE  maps  a  relation  onto  the  state  component  of  the  last  element  in  the  relation’s  state 
sequence.  If  the  relation’s  state  sequence  is  empty,  LASTSTATE  returns  error. 

We  now  define  formally  the  semantic  function  E  for  each  kind  of-expression  allowed  in  the 
language. 


Ef  [snapshot ,  M ,  S  ]  ]  (d,  n)  =  if  T[  [snapshot ,  M ,  S  ]  ]  (cf,  n)  ^  typeerror 

then  SfSj 
else  error 

EXAMPLE. 

Eff [snapshot ,  (sname: string,  class : string) ,  (sname : "Phil" ,  class junior")  , 

(snama : "Linda" ,  class : "senior") , 
(sname :  "Ralph" ,  class :  "senior" ) ] 
] (DS , 9)  =  {(“Phil”,  “junior”),  (“Linda”,  “senior”),  (“Ralph”,  “senior”)} 

□ 


E[[/]] (cZ,  n)  =  if  Tj/J(ci,  n)  5^  typeerror  then  LASTSTATE  (d(/))  else  error 


An  identifier  expression,  if  semantically  correct,  always  evaluates  to  the  current  state  of  the 
relation  denoted  by  I. 
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EXAMPLE. 


EfRl] (DS, 9)  =  {(250861414,  “junior”),  (147894290,  “senior”),  (459326889,  “senior”)} 

□ 


E|[.Ei  U  £2]](d,  n)  =  if  Tf£i  U  Ei]  (d,  n)  ^  typeerror 
then  Ej.Ei](d,  n)  U  E[£2](d,  n) 
else  ERROR 

The  definitions  of  E  for  the  other  four  snapshot  operators  are  analogous  to  that  for  the  union 
operator.  For  each  of  these  operators,  the  denotation  of  a  semantically  correct  expression  containing 
the  operator  is  defined  as  the  standard  snapshot  operator  over  the  denotation  of  the  argument(s) 
to  that  operator. 


El pU,  N)Ud,  n) 


if  T|p(7,  N)}(d,  n)  typeerror 
then  FINDSTATE  (d(J),  N[1V]) 
else  error 


A  semantically  correct  rollback  expression  evaluates  to  the  snapshot  state  of  the  relation  denoted 
by  I  at  the  time  of  transaction  N[fVJ.  The  rollback  operator  always  rolls  a  relation  backward, 
but  never  forward,  in  time.  Because  transactions  always  update  the  database  as  they  are  executed, 
postactive  changes  (i.e.,  changes  that  will  occur  in  the  future)  [Snodgrass  &  Ahn  1985]  need  not  be 
considered.  Postactive  changes  are  associated  only  with  valid  time,  not  transaction  time.  Recall 
from  the  definition  of  the  semantic  function  T  that  the  expression  is  semantically  correct  only  if 
the  relation  was  a  rollback  relation  when  the  transaction  was  processed. 
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EXAMPLES. 


Ejp(Rlf  4))(DS,9)  = 

{  (“Phil”,  250861414),  (“Linda”,  147894290),  (“Ralph”,  459326889)  } 

EfTrsnanwCpCRl.  4))J(DS,9)  =  {  (“Phil”),  (“Linda”),  (“Ralph”)  ) 

Elffsname (pOU >  4))  x  [  snapshot,  (course : string) ,  (course : "English")] 
] (DS, 9)  =  {  (“Phil”,  “English”),  (“Linda”,  “English”),  (“Ralph”,  “English”)  } 


The  semantic  function  E  for  expressions  involving  historical  operators  follows  directly.  The 
denotations  for  these  expressions  are  identical  to  those  for  expressions  involving  snapshot  operators, 
except  that  historical  and  temporal  are  substituted  for  snapshot  and  rollback,  respectively. 


2.5  Commands 

The  semantic  function  C  defines  the  denotation  of  commands  defined  syntactically  in  Section  2.1. 
C  defines  a  command  as  a  function  that  maps  a  database  state  and  a  transaction  number  onto  a 
database  state  and  a  status  code.  Execution  of  a  semantically  correct  command  produces  a  new 
database  state  and  the  status  code  OK,  indicating  that  the  command  was  successfully  executed. 
Execution  of  a  semantically  incorrect  command  produces  the  original  database  state  unchanged 
and  the  status  code  error,  indicating  that  the  command  could  not  be  executed. 


C  :  COMMAND  [  [  DATABASE  STATE  x  T  DAMS  ACTION  NUMBER.)  — 

[  DATABASE  STATE  x  (ok,  error)  ]  ] 


The  environment  for  command  execution  is  the  same  as  that  for  expression  type-checking  and  eval¬ 
uation,  a  database  state  and  the  transaction  number  of  the  active  transaction  (i.e.,  the  transaction 
in  which  the  command  being  executed  occurs).  A  command  produces  a  new  database  state  from 
the  given  database  state  by  changing  a  relation. 

We  use  semantic  type-checking  of  expressions  in  the  definition  of  C  to  restrict  evaluation  of 
expressions  to  semantically  correct  expressions  only.  We  also  incorporate  error-checking,  based  on 
the  type  system  for  expressions,  into  C’s  definition  to  guarantee  consistency  among  a  relation’s 
class,  signature,  and  state  following  update.  Error- checking  ensures  that  commands  actually  change 
relations  only  when  the  change  would  result  in  a  relation  with  compatible  class,  signature,  and  state. 
Commands  whose  execution  would  result  in  an  inconsistency  among  a  relation’s  class,  signature, 
and  state  are  effectively  ignored  (i.e,  they  do  not  alter  the  database  state). 
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1 


Before  defining  the  semantic  function  C,  we  describe  informally  several  additional  auxiliary 
functions  used  in  its  definition.  Formal  definitions  for  MSoT  and  its  subordinate  functions  appear 
in  Appendix  B.  Formal  definitions  for  the  other  functions  appear  in  [McKenzie  1988]. 

M'  is  the  same  as  the  semantic  function  M  with  the  exception  that  it  maps  the  special  symbol  * 
onto  a  relation’s  current  signature. 

Z'  is  the  same  as  the  semantic  function  Z  with  the  exception  that  it  maps  the  special  symbol  * 
onto  a  relation’s  current  class. 

CONSISTENT  is  a  boolean  function  that  determines  whether  a  class  and  signature  are  consistent 
with  an  expression’s  type. 

EMPTYSTATE  maps  a  relation  class  onto  the  empty  relation  state  consistent  with  the  class. 

MSoT  (Modified  Start  of  Transaction)  is  a  function  that  maps  a  relation  and  a  transaction 
number  onto  the  history  of  the  relation  as  a  rollback  or  temporal  relation  prior  to  the  start 
of  the  transaction  assigned  the  transaction  number.  We  refer  to  this  history  as  the  relation’s 
MSoT  for  that  transaction.  The  significance  of  MSoT  will  becomerapparent  when  we  discuss 
multiple-command  transactions. 

EXAMPLE.  Again  assume,  as  in  earlier  examples,  that  we  are  given  the  database  (DS,  8)  where 
the  database  state  component  maps  the  identifier  Ri  onto  the  relation  shown  in  the  example  on 
page  13. 

I 


MSoT  (Rl,  9)  = 


class 

signature 

state 

((rollback,  2,  6) 

(((sname  — ►  string, 
ssn  — ►  integer),  2), 

((0,2), 

({(“Phil”,  250861414), 
(“Linda”,  147894290), 
(“Ralph”,  459326889)},  4), 

((sname  — *  integer, 

({(“Phil”,  “junior”), 

class  — ►  string),  5) 

(“Linda”,  “senior”), 

) 

) 

(“Ralph”,  “senior”)},  5)  ) 

In  this  example,  MSoT  retains  Rl’s  history  as  a  rollback  relation  prior  to  transaction 9.  Although 
Rl’s  current  class,  signature,  and  state  were  recorded  before  the  start  of  transaction  9,  they  have 
been  discarded  because  they  are  not  part  of  Rl’s  history  as  a  rollback  relation.  If,  however,  the 
last  element  in  Rl’s  class  sequence  had  been  (rollback,  8,  -),  then  Rl’s  current  class,  signature, 
and  state  also  would  have  been  retained.  In  this  case,  MSoT  simply  would  have  changed  the 
second  transaction- number  component  of  the  last  element  in  Rl’s  class  sequence  to  8  to  indicate 
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that  the  resulting  relation  only  records  Rl’s  history  as  a.  rollback  relation  through  Tansaction  S. 
If  R1  had  never  been  a  rollback  or  temporal  relation,  then  MSoT  would  have  mapped  Rl  onto 
((),(),(>)■  □ 

EXTEND  replaces  the  second  transaction-number  component  in  the  last  element  of  a  relation’s 
MSoT  class  sequence  with  the  special  element  EXTEND  has  the  effect  of  making 

the  length  of  the  interval  for  the  class  component  of  this  element  dynamic,  extending  to  the 
present. 

NEWSIGNATURE  maps  a  relation’s  MSoT  and  a  (signature,  transaction  number)  pair  onto  the 
empty  sequence,  if  the  signature  in  the  last  element  of  the  relation’s  MSoT  signature  sequence 
is  equal  to  the  signature  in  the  (signature,  transaction  number)  pair,  or  a  one-element  sequence 
containing  the  (signature,  transaction  number)  pair,  otherwise. 

NEWSTATE  maps  a  relation’s  MSoT,  a  (relation  state,  transaction  number)  pair,  and  a  (class, 
signature)  pair  onto  the  empty  sequence,  if  the  class  and  signature  in  the  last  elements  of  the 
relation’s  MSoT  class  and  signature  sequences  are  consistent  with  the  (class,  signature)  pair 
and  the  state  in  the  last  element  of  the  relation’s  MSoT  state  sequence  is  equal  to  the  relation 
state  in  the  (relation  state,  transaction  number)  pair,  or  a  one-element  sequence  containing 
the  (relation  state,  transaction  number)  pair,  otherwise. 

We  define  formally  the  semantics  of  commands  using  the  same  approach  we  used  to  define 
the  semantics  of  expressions.  We  define  the  semantic  function  C  for  each  kind  of  command  al¬ 
lowed  in  the  language.  In  each  of  the  following  definitions,  the  predicate  specifies  the  conditions 
under  which  the  command  is  executed.  If  these  conditions  hold,  a  new  database  state  is  produced 
and  the  status  code  ok  is  returned;  otherwise,  the  database  state  is  left  unchanged  and  the  sta¬ 
tus  code  error  is  returned.  The  conditions  specified  in  each  definition  are  both  necessary  and 
sufficient  to  ensure  that  only  semantically  correct  expressions  are  evaluated  and  that  the  class, 
signature,  and  state  of  each  relation  in  the  database  state  following  execution  of  the  command  are 
consistent.  In  all  five  definitions  we  assume  that  if  oj,  a?,  03,  6j,  62,  and  63  are  all  sequences,  then 
(dj,  d2,  03)  ||3  ({>!,  bi,  63)  denotes  the  triple  (ai  ||  b\,  aj  ||  62,  a3 1|  63),  where  “||”  is  the  concatenation 
operator  on  sequences.  Also,  the  notation  d[r  /I]  stands  for  a  new  database  state  that  differs  from 
the  database  state  d  only  in  that  it  maps  the  identifier  I  onto  the  relation  r. 

2.5.1  Define_relation 

The  def  ine_relation  command  assigns  to  a  relation,  whose  current  class  is  undefined,  a  new 
class  and  signature  and  the  empty  relation  state  consistent  with  the  new  class.  The  assignment 
becomes  effective  when  the  transaction  in  which  the  command  occurs  is  committed.  The  changes 
that  the  command  makes  to  the  relation  to  effect  this  assignment  depend  on  the  relation’s  current 
class;  the  last  class,  signature,  and  state,  if  any,  in  the  relation’s  MSoT  for  the  transaction  in 
which  the  command  occurs;  and  whether  the  new  class  is  a  single-state  class  (i.e.,  snapshot  or 
historical)  or  a  multi-state  class  (i.e.,  rollback  or  temporal).  We  hereafter  refer  to  the  last 
class,  signature,  and  state  in  a  relation’s  MSoT,  if  present,  as  the  relation’s  MSoT  class,  signature, 
and  state,  respectively.  The  actions  performed  by  the  def ina_relation  command,  for  all  possible 
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Current  Class  New  Class 


SingleStateClass 

MultiStateClasa 

New  Class 
Extends 

MSoT  Class 

Not  Applicable 

1 

Extend  MSoT 
Append  to  MSoT, 
if  Changed 
Append  to  MSoT, 
if  Changed 

New  Class 

Does  Not  Extend 
MSoT  Class 

2 

Append  to  MSoT 
Append  to  MSoT, 
if  Changed 

Append  to  MSoT, 
if  Changed 

Append  to  MSoT 
Append  to  MSoT, 
if  Changed 
Append  to  MSoT, 
if  Changed 

SingleStateClass 

^  Error 

Error 

MultiStateClasa 

Error 

Error 

Table  1:  Defme_relation  Command 

combinations  of  these  variables,  can  be  reduced  to  the  three  cases  shown  in  Table  1. 

If  the  relation’s  current  class  is  undefined,  the  definejrelation  command  replaces  the 
relation  with  its  MSoT,  augmented  to  include  the  new  class,  signature,  and  state.  If  the  new 
class  represents  a  non-disjoint  extension  of  the  relation’s  MSoT  class,  the  interval  assigned  the 
MSoT  class  is  extended  (i.e.,  made  into  a  dynamically  expanding  interval  by  changing  the  second 
transaction-number  component  to  to  include  tire  transaction  in  which  the  command  occurs. 
This  case  is  limited  to  def ine_relation  commands  in  multiple-command  transactions,  which  we 
discuss  in  Section  2.5.5.  Otherwise,  the  new  class  is  appended  to  the  MSoT  class  sequence.  In 
either  case,  a  new  signature  (state)  is  added  to  the  MSoT  signature  (state)  sequence  only  if  it 
differs  from  the  MSoT  signature  (state).  If  the  relation’s  current  class  is  other  than  undefined, 
the  command  encounters  an  error  condition  and  leaves  the  relation  unchanged. 

The  formal  definition  of  def  ine_relation  follows  directly  from  Table  1. 


» 
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C[define_relation(/,  Z,  M)\(d,  n)  = 

if  (r  =  MSoT  (d(I),  n )  A  LASTCLASS  (d(I))  =  undefined 
AZ|ZJ  ERROR  A  M|M]j  ^  error) 
then  if  FINDCLASS  (r,  n  -  1)  =  Z[Z] 
then  (d[(EXTEND(r)  ||3 

«>, 

NEWSIGNATURE  (r,  (M{Ml  n)), 

NEWSTATE(r,  (EMPTYSTATE(Z[ZJ),  n),  (Z[ZJ,  M[MJ))) 
)//],  ok) 

else  (d{(r\\*(mZln,-)), 

NEWSIGNATURE  (r,  (M[MJ,  n)), 

NEWSTATE (r,  (EMPTYSTATE(Z[Zf),  n),  (Z [Z],  MfAfJ))) 

)/I),  OK) 
else  (<f,  error) 


where  r  ranges  over  the  domain  HSCATTOM  +  {^{  ),(),(  ))}. 


I 


EXAMPLES.  In  these,  and  later  examples,  we  show  the  result  of  executing  a  sequence  of  commands, 
starting  with  the  database  (DS,  8).  We  assume  that  each  command  corresponds  to  a  single¬ 
command  transaction  that  commits.  For  simplicity,  we  always  refer  to  the  current  database  state 
as  DS,  although  it  changes  with  each  command’s  execution  (i.e.,  transaction’s  commitment).  We 
also  restrict  the  commands  to  the  relations  denoted  by  the  identifiers  Rl,  R2,  and  R3  and  show 
only  the  portion  of  the  database  state  changed  by  each  command’s  execution.  We  assume  that  DS 
maps  the  identifiers  R2  and  R3  onto  the  following  relations. 


class 

signature 

state 

R2— + 

((rollback,  1,  5), 

(((enaae  — ►  string, 
ssn  — >  integer),  1) 

((0,  1), 

({(“Phil”,  250861414), 
(“Linda”,  147894290), 
(“Ralph”,  459326889)},  3) 

(undefined,  6,  -)) 

) 

*  ) 

( 
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class 


R3- 


((UNDEFINED,  0,  -))  ]  (] 


signature  state 


77 


Note  that  a  relation  whose  current  class  is  undefined  has  neither  a  current  signature  nor  a  current 
state.  The  relation  denoted  by  R2  has  a  MSoT  signature  (state),  but  not  a  current  signature  (state). 
The  relation  denoted  by  R3  has  neither  a  MSoT  signature  (state)  nor  a  current  signature  (state). 


C[define_relation(R2,  rollback,  (ename  .-string,  ssn: integer) )} (DS,  9) 


class 

signature 

state 

R2— <• 

((rollback,  1,  5), 

(((ename  — »  string, 
ssn  — ►  integer),  1) 

"PTTk 

({(“Phil”,  250861414), 
(“Linda”,  147894290), 

( “Ralph”r459326889 ) } ,  3), 

(rollback,  9,  -) ) 

) 

(0,9)  > 

C(definejrelation(R3,  snapshot,  (sname: string,  class: string) )|(DS,  10) 


class 

signature 

state 

R3— > 

((snapshot,  10,  -) 

(((sname  — ►  string, 

((0,  io) 

) 

class  — ►  string),  10)) 

) 

The  first  command  makes  the  relation  denoted  by  R2  a  rollback  relation  over  the  attributes  ename 
and  ssn,  effective  when  transaction  9  commits.  Although  the  new  class  and  the  relation’s  MSoT 
class  are  equal,  the  intervals  associated  with  the  two  are  disjoint.  Hence,  the  new  class  is  appended 
to  the  relation’s  MSoT  class  sequence.  The  new  signature  is  not  appended  to  the  relation’s  MSoT 
signature  sequence  because  it  is  the  same  as  the  relation’s  MSoT  signature.  The  new  state,  the 
empty  set,  differs  from  the  relation’s  MSoT  state.  Hence,  it  is  added  to  the  relation’s  MSoT  state 
sequence.  The  second  command  makes  the  relation  denoted  by  R3  a  snapshot  relation  over  the 
attributes  sname  and  class,  effective  when  transaction  10  commits.  Because  the  relation’s  MSoT  at 
transaction  10  is  ((),(),() ),  the  command  transforms  the  relation’s  class,  signature,  and  state 
sequences  into  single-element  sequences  containing  the  new  class,  signature,  and  state.  Note  that 
information  about  both  relations  when  they  were  undefined  has  been  discarded  as  it  is  not  needed 
for  rollback.  □ 


Current  Class  New  Class 


SingleS tate  Class 

MoltiStateClass 

New  Class 
Extends 

MSoT  Class 

SingleS  tateClass 

Not  Applicable 

Extend  MSoT 
Append  to  MSoT, 
if  Changed 
Append  to  MSoT, 
if  Changed 

MultiStateCLass 

New  Class 

Does  Not  Extend 
MSoT  Cla?-. 

2 

Append  to  MSoT 
Append  to  MSoT, 
if  Changed 

Append  to  MSoT, 
if  Changed 

Append  to  MSoT 
Append  to  MSoT, 
if  Changed 
Append  to  MSoT, 
if  Changed 

Undefined 

3  Error 

JEjrror 

Table  2:  Modify  .relation  Command 


2.5.2  Modify  jrelation 

I 

The  modif  y  jrelation  command  assigns  to  a  relation,  whose  current  class  is  other  than  undefined, 
a  new  class,  signature,  and  relation  state.  The  assignment  becomes  effective  when  the  transaction 
in  which  the  command  occurs  is  committed.  The  modify  jrelation  command  differs  from  the 
def  inejrelation  command  in  only  three  respects.  First,  the  modif  y  jrelation  command  only 
|  updates  a  relation  if  its  current  class  is  not  undefined,  whereas  the  def inejrelation  command 

does  just  the  opposite.  Second,  the  nodifyjrelation  command,  unlike  the  define_relation 
command,  allows  the  new  class  (signature)  to  be  the  relation’s  current  class  (signature).  Third, 
the  modify_relation  command  allows  the  new  relation  state  to  be  the  value  of  any  semantically 
correct  expression  consistent  with  the  new  class  and  signature,  whereas  the  def  inejrelation 
command  requires  that  the  new  state  be  the  empty  state  consistent  with  the  new  class.  Otherwise, 
*  the  semantics  of  the  two  commands  is  the  same.  The  actions  performed  by  the  def  inejrelation 

command  are  summarized  in  Table  2. 


The  formal  definition  of  modifyjrelation  follows  directly  from  the  above  description  of  the 
command  and  Table  2. 
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ClmodifyjralationC/,  Z' ,  M' ,  E)](d,  n)  = 

if  (r  =  MSoT(d(/),  n)  A  LASTCLASS  (d(J))  ^  undefined 

A  CONSISTENT  (Z'jJZ'l  (d( /)),  M'fM']  (d(I)),  T [E](d,  n ))) 
then  if  FINDCLASS  (r,  n  -  1)  =  Z\ Z'\{d(I)) 
then  (d  [  (EXTEND  (r)  ||3 
((). 

NEWSIGNATURE  (r,  (M'fM'](d(J)),  n)), 
NEWSTATE(r,  (E[£l(d,  n),  n),  T[£l(d,  n ))) 
)//],  ok) 

else  (d[(r||3(((Z'IZ'](d(/)),n,-)), 

NEWSIGNATURE  (r,  (M'fM'l  (d(J)),  n)), 
NEWSTATE  (r,  (E[£3(d,  n),  n),  T[£J(d,  n))) 
)//],  ok) 
else  (d,  error) 


If  a  relation’s  current  class  is  other  than  undefined,  the  modify  .relation  command  replaces  the 
relation  with  its  MSoT,  augmented  to  include  the  new  class,  signature,  and  state.  If  the  relation’s 
current  class  is  undefined,  the  command  encounters  an  error  and  leaves  the  relation  unchanged. 

EXAMPLES. 

C[modif y_relation(R2 ,  *,  *,  p(R2,5)  -  ^enama=" Ralph" (p(R2,5)))]|(DS,  11) 


class 

signature 

state 

R2— 

((rollback,  1,  5), 

(((ename  — *•  string, 
ssn  — *•  integer),  1) 

({(“Phil”,  250861414), 

(“Linda”,  147894290), 
(“Ralph”,  459326889)},  3), 

(rollback,  9,  -) 

(0,9), 

) 

) 

({(“Phil”,  250861414), 

(“Linda”,  147894290)},  11)) 
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Clmodify_relation(R3,  *,  *,  p(Rl  ,5) )]  (DS,  12) 


class 

signature 

state 

R3-+ 

((snapshot,  12,  -) 

(((sname  — ►  string, 

(({(“Phil”,  “junior”), 

class  -*  string),  12) 

(“Linda”,  “senior”), 

) 

) 

(“Ralph”,  “senior”)},  12)) 

The  first  command  changes  the  state  of  the  relation  denoted  by  R2  while  the  second  command 
changes  the  state  of  the  relation  denoted  by  R3.  The  commands,  however,  do  not  change  the  class 
or  signature  of  either  relation.  For  the  first  command,  the  new  class  (i.e.,  R2’s  current  class)  is  a 
non-disjoint  extension  of  R2’s  MSoT  class.  Hence,  the  interval  for  R2’s  MSoT  class  is  made  into 
a  dynamically  expanding  interval  that  includes  transaction  11,  but  no  new  element  is  added  to 
R2’s  MSoT  class  sequence.  The  new  signature  (i.e.,  R2’s  current  signature)  is  the  same  as  R2’s 
MSoT  signature,  hence  it  is  not  added  to  R2’s  MSoT  signature  sequence.  The  new  state  differs 
from  R2’s  MSoT  state,  hence  it  is  appended  to  R2’s  MSoT  state  sequence.  Because  R3’s  MSoT 
at  transaction  12  is  still  ((),(),()),  the  second  command  transforms~R3’s  class,  signature,  and 
state  sequences  into  single-element  sequences  containing  the  new  class  (i.e.,  R3’s  current  class), 
signature  (i.e.,  R3’s  current  signature),  and  state.  Note  that  R2’s  state  at  transaction  9  through 
transaction  10  has  been  retained  and  remains  accessible  via  the  rollback  operator  p,  but  R3’s  state 
before  transaction  12  has  been  discarded  (i.e.,  physically  deleted  from  the  database  state). 


C[modify_relation(R3,  *,  (sname: string,  course : string)  , 

tfsname (R3)  X  [snapshot,  (course : string) , 

(course:"English")])]|(DS,  13) 


class 

signature 

state 

R3— ► 

((snapshot,  13,  -) 

(((sname  — ►  string, 

1  (({(“Phil”,  “English”), 

course  — ♦  string),  13) 

(“Linda”,  “English”), 

) 

> 

(“Ralph”,  “English”)},  13)) 

This  command  changes  R3’s  signature  and  state  but  leaves  the  relation’s  class  unchanged.  It 
illustrates  two  possible  changes  to  a  relation’s  signature,  deletion  of  one  attribute  and  addition  of 
another  attribute.  Deletion  of  an  attribute  is  usually  expressed  as  a  projection  over  the  remaining 
attributes.  Addition  of  an  attribute  requires  that  a  value  for  the  new  attribute  be  determined  for 
each  tuple  in  the  relation.  Often,  as  in  this  example,  a  single  default  value  is  specified,  tthich  is  then 
appended  to  each  tuple.  Note  again  that  R3’s  state  before  transaction  13  has  been  discarded.  □ 

The  modify_relation  command  has  several  noteworthy  properties.  First,  the  command 
supports  all  update  operations  on  a  relation’s  state.  Append  is  accommodated  by  an  expression  E, 
generally  containing  a  union  operator,  that  evaluates  to  a  snapshot  or  historical  state  containing 
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all  the  tuples  in  a  relation’s  current  state  plus  one  or  more  tuples  not  in  the  relation’s  current 
state.  Delete  is  accommodated  by  an  expression  E,  generally  containing  a  difference  operator, 
that  evaluates  to  a  snapshot  or  historical  state  containing  only  a  proper  subset  of  the  tuples  in  a 
relation’s  current  state.  Replace  is  accommodated  by  an  expression  E  that  evaluates  to  a  snapshot 
or  historical  state  that  differs  from  a  relation’s  current  state  only  in  the  attribute  values  of  one  or 
more  tuples. 

Second,  the  modif  y  .relation  command  ensures  that  a  relation’s  class,  signature,  and  state 
are  consistent  following  update.  The  command  changes  a  relation’s  state  only  if  the  new  state  is 
consistent  with  the  relation’s  class  and  signature.  Whenever  the  command  changes  a  relation’s 
signature,  it  also  changes  the  relation’s  state  to  ensure  consistency  among  the  relation’s  class, 
signature,  and  state  [Navathe  L  Fry  1976].  Likewise,  whenever  the  command  changes  a  relation’s 
class,  it  also  updates  the  relation’s  state,  if  necessary,  to  ensure  consistency  among  the  relation’s 
class,  signature,  and  state. 

Finally,  the  modify_relation  command  always  treats  a  relation’s  signature  (state)  sequence 
as  an  append-only  sequence  when  the  relation’s  current  class  is  either  rollback  or  temporal,  but  it 
does  not  automatically  discard  a  relation’s  current  signature  (state)  on  update  even  if  the  relation’s 
current  class  is  snapshot  or  historical.  If  a  relation’s  current  class  is'  a  single-state  class,  the 
command  discards  the  relation’s  current  signature  (state)  on  update  only  if  the  signature  (state) 
is  not  part  of  the  relation’s  history  as  a  rollback  or  temporal  relation. 


2.5.3  Delete_reIation 

The  command  delete_relation  assigns  to  a  relation,  whose  current  class  is  other  than  unde¬ 
fined,  the  new  class  undefined.  It  also  deletes,  either  logically  or  physically,  the  relation’s  current 
signature  and  state. 

C[delete_relation(/)J(d,  n)  = 

if  r  =  MSoT  ( d{I ),  n)  A  LASTCL  ASS  (d(J))  ^  undefined 
then  (<f[(r  ||3  (((undefined,  n,  -)),  (),()) 

)//],  OK) 
else  (d,  error) 


If  the  identifier  /  denotes  a  relation  whose  current  class  is  other  than  undefined,  the  command 
simply  appends  the  new  class  undefined  to  the  relation’s  MSoT  for  the  transaction  in  which  the 
command  occurs. 
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EXAMPLES. 


C[delete_relation(R2)](DS,  14) 


class 

signature 

state 

((rollback,  1,  5), 

(((ename  — »  string, 
ssn  — ►  integer),  1) 

~WAT, 

({(“Phil”,  250861414), 

(“Linda”,  147894290), 
(“Ralph”,  459326889)},  3), 

(rollback,  9,  13), 

(•.  9), 

({(“Phil”,  250861414), 

(“Linda”,  147894290)},  11) 

(undefined,  14,  -)) 

) 

> 

C[delete_relation(R3)  J(DS,  15) 


class 


R3— ►  I  ((undefined,  15,  -))  (7 


signature  state 
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Because  R2  denotes  a  relation  whose  current  class  is  rollback,  the  first  command  uses  the  function 
MSoT  to  “close”  the  interval  associated  with  the  relation’s  current  class.  It  then  appends  the 
element  (undefined,  14,  -)  to  R2’s  class  sequence.  These  actions  together  have  the  effect  of  logically 
deleting  R2’s  current  signature  and  state  when  transaction  14  commits.  Note,  however,  that  this 
signature  and  state  information  is  still  accessible  via  the  rollback  operator  p.  The  second  command 
uses  the  function  MSoT  to  physically  delete  R3’s  current  class,  signature,  and  state.  No  record  of 
R3  as  a  snapshot  relation  is  retained.  □ 

It  is  important  to  observe  from  these,  and  previous,  examples  that  signature  and  state  infor¬ 
mation  associated  with  a  relation  when  its  class  was  either  snapshot  or  historical  was  transient. 
It  was  physically  removed  when  it  became  outdated.  Hence,  the  language  is  consistent  with  con¬ 
ventional  relational  DBMS’s  that  discard  out-of-date  signature  and  state  information, (relation  R3 
illustrates  this).  However,  signature  and  state  information  associated  with  a  relation  when  its  class 
was  rollback  or  temporal  is  retained,  ensuring  later  access  to  past  states  via  the  rollback  operator. 
Definition  of  the  rollback  operator  assumes  access  to  a  complete  record  of  a  relation’s  signature 
and  state  during  intervals  when  the  relation’s  class  was  either  rollback  or  temporal. 
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2.5.4  Rename-relation 


The  command  rename_relation  binds  a  relation’s  current  class,  signature,  and  state  to  a  new 
identifier. 

C[rename_relation(/i ,  /2>](d,  n)  = 

if  (LASTCLASS  (d(/i))  ^  undefined  A  LASTCLASS  (d(/2))  =  undefined 
AZ \Z\  =  LASTCLASS  (d(/i))  A  M[M|  =  L ASTSIGNATURE  (d(/j )) 

A  C|define_r#lation(/2 ,  Z ,  AQ](d,  n)  =  (d',  ok) 
a  Cfmodify_relation(/2,  *,  *, /i)]  (d',  n)  =  (d",  ok) 

A  CJdelete_relation(/i)](d",  n)  =  (d'",  ok)) 
then  (d'",  ok) 
else  (d,  error) 


The  rename_relation  first  assigns  to  the  relation  denoted  by  1 2  the  current  class  and  signature 
of  the  relation  denoted  by  l\.  It  then  assigns  to  72  the  current  state  of  l\.  Finally,  it  assigns  the 
class  undefined  to  Jj  and  deletes,  either  logically  or  physically,  I\  s  current  signature  and  state. 
Note  that  the  execution  environments  for  rename_relation’s  three  subordinate  commands,  while 
containing  different  database  states,  contain  the  same  transaction  number.  Hence,  the  changes  to 
both  1\  and  I2  become  effective  when  a  single  transaction  commits. 

EXAMPLE.  Recall  that  R1  is  the  relation  shown  on  page  13. 


C[rename_relation(Rl ,  R3)]|(DS,  16) 


class 

signature 

state 

Rl— *• 

{(rollback,  2,  6), 

{((sname  — *•  string, 
ssn  -♦  integer),  2), 

««■  2). 

({(“Phil”,  250861414), 
(“Linda”,  147894290), 
(“Ralph”,  459326889)},  4), 

((sname  — ►  string, 
class  — *•  string),  5) 

({(“Phil”,  “junior”), 

(“Linda”,  “senior”), 
(“Ralph”,  “senior”)},  5) 

(undefined,  16,  -)) 

) 

) 
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class 

signature 

state 

R3— *• 

{(snapshot,  16,  -) 

{((ssn  — »  integer, 

{({(250861414,  “junior”), 

class  — ♦  string),  16) 

(147894290,  “senior”), 

) 

) 

(459326889,  “senior”)},  16)) 

This  command  binds  the  current  class,  signature,  and  state  of  the  relation  denoted  by  R1  to  the 
identifier  R3.  Hence,  R3  becomes  a  snapshot  relation  when  transaction  16  commits.  The  command 
also  transforms  R1  into  an  undefined  relation,  effective  when  transaction  16  commits.  Because 
Rl’s  current  class,  signature,  and  state  are  not  part  of  the  relation’s  history  as  either  a  rollback  or 
temporal  relation,  they  are  physically  deleted.  □ 


2.5.5  Ci,  C2 

If  two  or  more  commands  appear  in  sequence,  the  commands  are  executed  sequentially.  If  a 
command  executes  without  error,  the  next  command  is  executed  using  the  database  state  resulting 
from  the  previous  command’s  execution.  If  all  the  commands  execute  without  error,  the  commands 
are  mapped  onto  the  final  database  state  and  the  status  code  ok.  If,  however,  any  command’s 
execution  causes  an  error,  the  remaining  commands  are  not  executed  and  all  the  commands  together 
are  mapped  onto  the  original  database  state  and  the  status  code  error. 


C[Clf  C2J(d,  n)  =  if  C[Ci](d,  n)  =  (d\ ok)  then  C[C2J(d',  n)  else  (d,  error) 


Two  or  more  commands  appearing  in  sequence  are  all  commands  in  the  same  transaction.  Their 
execution  environments  have  different  database  states  but  the  same  transaction  number.  Hence,  if 
the  commands  change  the  same  relation  only  the  last  changes  to  the  relation’s  class,  signature,  and 
state  are  recorded  in  the  final  database  state.  Recall  that  while  a  relation’s  new  class,  signature, 
and  state  may  depend  on  its  current  class,  signature,  and  state,  all  commands  define  the  resulting 
relation  in  terms  of  the  relation’s  modified  start  of  transaction.  Also,  if  the  commands  change 
several  relations,  all  the  changes  become  effective  when  the  transaction  commits. 

EXAMPLES.  In  the  previous  examples,  we  assumed  that  the  commands  were  all  taken  from  single¬ 
command  transactions.  We  now  show  the  result  of  executing  multiple  commands  from  the  same 
transaction.  Recall  from  page  33  that  R2  is  currently  undefined. 

C[def  ine_relation(R2,  rollback,  (ename: string,  ssn: integer) )  , 
modify_relation(R2,  *,  *,  p(R2,5)), 

modify  _relation(R2 ,  *,  *,  R2  -  cr8nama»" Linda"  CR2>>1  (DS,  17) 
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R2 


class 

ROLLBACK,  1,  5), 


signature 
(ename  — *•  string, 
ssn  — *■  integer),  1) 


ww. 


state 


({(“Phil”,  250861414), 

(“Linda”,  147894290), 
(“Ralph”,  459326889)},  3), 

(rollback,  9,  13), 

(0,  9), 

({(“Phil”,  250861414), 

(“Linda”,  147894290)},  11), 

(rollback,  17,  -) 

) 

) 

({(“Phil”,  250861414), 

(“Ralph”,  459326889)},  17)) 

C[delote_r«lation(R2)  ,  delete_relation(R3)J(DS,  18) 


class 

signature 

state 

((rollback,  1,  5), 

(((ename  — ►  string, 
ssn  — ►  integer),  1) 

ft®,  i). 

({(“Phil”,  250861414), 

(“Linda”,  147894290), 
(“Ralph”,  459326889)},  3), 

(rollback,  9,  13), 

(0,  9), 

({(“Phil”,  250861414), 

(“Linda”,  147894290)},  11), 

(rollback,  17,  17) 

({(“Phil”,  250861414), 

(“Ralph”,  459326889)},  17) 

(undefined,  18,  -)) 

) 

) 

class 


R3-*  I  ((undefined,  18,  -))  f") 


signature  state 


0 


In  the  first  example,  all  three  commands  change  R2.  Yet,  only  the  last  changes  to  the  relation’s 
class,  signature,  and  state  are  recorded  in  the  database  state.  Although  the  first  command  defined 
82  as  a  rollback  relation  and  the  other  commands  changed  R2’s  state,  only  the  final  change  in  state 
is  recorded.  Hence,  all  the  commands  in  a  single  transaction  that  change  the  same  relation  are 
treated  as  an  atomic  update  operation.  Note  that  temporary  relations  can  be  defined,  modified, 
and  then  deleted  within  a  transaction  without  their  creation  being  recorded.  In  the  second  example, 
both  R2  and  E3  are  deleted  when  transaction  18  commits.  □ 
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2.6  Programs 

The  semantic  function  P  defines  the  denotation  of  programs  in  our  language,  where  a  program  is 
a  sequence  of  one  or  more  transactions,  transactions,  in  turn,  may  be  either  single-command  or 
multiple-command  transactions.  P  defines  a  program  as  a  function  that  maps  a  database  onto  a 
database  and  a  status  code.  A  program  is  the  only  language  construct  that  changes  a  database. 
Execution  of  a  transaction  that  commits  produces  a  new  database  and  the  status  code  ok,  while 
execution  of  a  transaction  that  aborts  produces  the  original  database  unchanged  and  the  status 
code  ERROR. 

P  :  VTZOg-RAM  —  [V ATABASS  —  [VATABASC  x  {ok,  error}]  ] 

Note  that  the  environments  for  command  and  program  execution,  although  similar,  are  different. 
The  environment  for  command  execution  is  a  database  state  and  the  transaction  number  of  the 
active  transaction.  In  contrast,  the  environment  for  program  execution  is  a  database,  which  is 
an  ordered  pair  consisting  of  a  database  state  and  the  transaction  number  of  the  most  recently 
committed  transaction  on  that  database  state. 

We  now  define  formally  the  semantic  function  P  for  each  kind  of  program  allowed  in  our 
language. 


P[begin_transaction  C  conmit_transaction]](d,  n)  = 

if  C[C][(d,  n+l)=  (d\  ok)  then  ((d1,  n  +  1),  ok)  else  (( d ,  n),  error) 


Committed  transactions  represent  transactions  that  commit  if  their  commands  all  execute 
without  error.  If  all  the  commands  in  a  transaction  execute  without  error,  the  transaction  is  com¬ 
mitted.  The  database’s  database-state  component  is  updated  to  record  the  changes  that  the  com¬ 
mands  make  to  relations,  the  database’s  transaction-number  component  is  incremented  to  record 
the  transaction  number  of  this  most  recently  committed  transaction,  and  the  status  code  ok  is  pro¬ 
duced.  If  any  command’s  execution  produces  an  error,  the  transaction  is  aborted.  The  database  is 
left  unchanged  and  the  status  code  error  is  produced.  The  database  is  valid  independent  of  the 
status  code. 


P[begin_transaction  C  abort_transaction]](d,  n)  =  (( d ,  n),  ok) 

Aborted  transactions  are  transactions,  which  the  user  initiates,  that  for  some  reason,  dictated 
either  by  the  user  or  by  the  system,  abort  rather  than  commit.  They  do  not  change  the  database. 


P[Pt;  P2](<f,n)  = 

if  PPM(<*,  n)  =  ((</',  »'),  ok)  then  P[P2J (<*',  n')  else  P[P2](d,  n) 
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If  a  program  contains  multiple  transactions,  they  .are  processed  in  sequence.  If  the  first 
transaction  commits  and  produces  a  new  database,  the  second  transaction  is  processed  using  the 
new  database.  Otherwise,  the  second  transaction  is  processed  using  the  original  database. 

Finally,  we  require  that  each  arbitrary  sequence  of  transactions  representing  a  program  map 
onto  the  database  resulting  from  the  execution  of  the  transactions,  in  order,  starting  with  the  empty 
database.  The  empty  database,  (EMPTY,  0),  is  defined  using  the  semantic  function  EMPTY  : 
TDEATTTIETl.  — ►  (  {(undefined,  0,  -)),  {),{)).  Hence,  the  database-state  component  of  the 
empty  database  is  defined  to  be  the  function  that  maps  all  identifiers  onto  undefined  relations;  the 
transaction-number  component  of  the  empty  database  is  defined  to  be  0.  This  requirement  is  both 
necessary  and  sufficient  to  ensure  that  the  transaction-number  components  of  elements  in  the  class, 
signature,  and  state  sequences  of  each  relation  in  the  database  are  strictly  increasing.  A  database 
will  always  be  the  cumulative  result  of  all  the  transactions  that  have  been  performed  on  it  since  it 
was  created. 

We  now  define  the  semantic  function  P'  that  maps  a  program  onto  the  database  resulting 
from  the  execution  of  the  program’s  transactions,  starting  with  the  empty  database. 


P'  :  VTIOQUAM  —  DATABASE 


P'fPI  =  FIRST(Pf.P]](EMPTY,  0)) 

where  FIRST  is  the  function  that  maps  an  ordered  pair  onto  the  first  component  of  the  ordered 
pair. 

2.7  Language  Properties 

We  now  state,  as  theorems,  three  properties  of  our  algebraic  language  for  database  query  and 
update.  Informal  proofs  of  these  theorems  are  given  in  Appendix  A.  The  first  property  was  stated 
initially  as  an  objective  of  our  extensions. 


Theorem  1  The  language  is  a  natural  extension  of  the  relational  algebra  for  database  query  and 
update. 


By  natural  extension,  we  mean  that  our  semantics  subsumes  the  expressive  power  of  the  relational 
*  algebra  for  database  query  and  update.  Expressions  in  our  language  are  a  strict  superset  of  those 

in  the  relational  algebra.  Also,  if  we  restrict  the  class  of  all  relations  to  undefined  and  snapshot, 
then  a  natural  extension  imples  that  (a)  the  signature  and  state  sequences  of  a  defined  relation  vill 
have  exactly  one  element  each:  the  relation’s  current  signature  and  state;  (b)  a  new  state  always 
will  be  a  function  of  the  current  signature  and  state  of  defined  relations  via  the  relational  algebra 
I  semantics;  and  (c)  deletion  will  correspond  to  physical  deletion. 
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The  second  property  argues  that  the  semantics  is  minimal,  in  a  specific  sense. 


Theorem  2  The  semantics  of  the  language  minimizes  the  number  of  elements  in  a  relation’s  class, 
signature,  and  state  sequence  needed  to  record  the  relation’s  current  class,  signature,  and  state  and 
its  history  as  a  rollback  or  temporal  relation. 


Other  definitions  of  minimality,  such  as  minimal  redundancy  or  minimal  space  requirements,  are 
more  appropriate  for  the  physical  level,  where  actual  data  structures  are  implemented,  than  for 
the  algebraic  level. 

The  third  property  ensures  that  the  language  accommodates  implementations  that  use  WORM 
optical  disk  to  store  non-current  class,  signature,  and  state  information,  another  objective  of  our 
extensions. 


Theorem  3  Transactions  change  only  a  relation’s  class,  signature,  and  state  current  at  the  start 
of  the  transaction. 


3  Additional  Aspects  of  the  Rollback  Operators 

The  rollback  operators  in  our  language  are  more  powerful  than  suggested  in  the  previous  section 
in  several  ways.  First,  the  rollback  operators,  as  defined,  are  restricted  to  the  retrieval  of  a  single 
snapshot  or  historical  state  from  a  named  relation  current  at  the  time  of  a  specified  transaction. 
In  reality,  however,  the  rollback  operators  derive  a  single  snapshot  or  historical  state  from  one 
or  more  of  the  named  relation’s  stored  states  rather  than  simply  retrieving  a  single  state.  The 
rollback  operators  actually  roll  back  a  relation  to  the  subsequence  of  the  relation’s  state  sequence 
corresponding  to  an  interval  of  time  of  arbitrary  length,  if  the  relation’s  class  and  signature  remained 
constant  over  that  interval  of  time.  The  rollback  operators  return  the  single  state  composed  of 
tuples  from  ail  the  states  in  the  specified  subsequence  of  relation  states  (effectively,  a  relational 
union,  either  snapshot  or  historical,  is  performed).  The  rollback  operators  thus  take  two  transaction 
times  as  arguments: 


E  ::=  p(I,N,N)  \  pU ,  N ,  N) 


Second,  the  rollback  operators  do  not  simply  retrieve  a  snapshot  or  historical  state  from  a 
named  relation  but  rather  an  augmented  version  of  that  state.  To  the  state’s  explicit  attributes, 
defined  in  its  signature,  the  rollback  operators  add  new  explicit  attributes  corresponding  to  the 
state’s  implicit  time  attributes  (i.e.,  transaction  times  for  snapshot  states,  transaction  and  valid 
times  for  historical  states).  The  rollback  operators’  addition  of  these  new  attributes  to  the  state’s 
existing  explicit  attributes  allows  the  user  to  display  the  values  of  the  state’s  implicit  me  attributes 
without  allowing  direct  access  to  the  attributes  themselves.  These  explicit  values  are  considered 
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to  be  in  the  domain  of  user-defined  time.  This  behavior  requires  that  the  semantic  function  T 
compute  a  relational  signature  containing  these  additional  attributes. 


Third,  the  rollback  operator  p  can  be  applied  to  temporal  relations  as  well  as  rollback  relations. 
If  p  rolls  back  a  relation  to  a  time  when  the  relation’s  class  was  temporal,  p  will  convert  the 
relation’s  historical  state  current  at  that  time  into  a  corresponding  snapshot  state  and  return  this 
new  snapshot  state.  Likewise,  the  rollback  operator  p  can  be  applied  to  rollback  relations  as  well 
as  temporal  relations.  If  p  rolls  back  a  relation  to  a  time  when  the  relation’s  class  was  rollback,  p 
will  convert  the  relation’s  snapshot  state  current  at  that  time  into  a  corresponding  historical  state 
and  return  this  new  historical  state. 

While  these  extensions  are  conceptually  straightforward,  the  notation  required  to  define  them 
formally  is  cumbersome  and  will  not  be  presented  here. 


I 

4  Summary  and  Related  Work 

In  summary,  this  paper  has  defined  an  algebraic  language  for  database  query  and  update  that 
subsumes  the  relational  algebra,  can  accommodate  an  arbitrary  historical  algebra,  and  supports 
both  snapshot  and  historical  rollback.  The  language  also  has  a  simple  semantics  and  supports 
scheme  evolution.  Only  two  additional  operators,  p  and  p,  were  necessary.  The  additions  required 
for  transaction  time  did  not  compromise  any  of  the  useful  properties  of  the  (conventional)  snapshot 
algebra.  Type-checking  was  also  introduced,  freeing  the  encapsulated  algebra  from  dealing  with 
expressions  not  consistent  with  the  (possibly  time-varying)  scheme. 

The  primary  contribution  is  an  algebraic  means  of  supporting  scheme  evolution  in  the  context 
of  general  support  for  transaction  time.  As  an  algebraic  language  for  database  query  and  update, 
our  language  can  serve  as  the  underlying  evaluation  mechanism  for  queries  and  updates  in  a  tem¬ 
poral  data  manipulation  language  that  supports  evolution  of  a  database’s  contents  and  scheme.  It 
can  also  be  used  as  the  basis  for  proving  various  physical  implementations  of  temporal  database 
management  systems  correct.  Our  language  also  is  compatible  with  efforts  to  add  transaction  time 
to  the  relational  data  model  at  both  the  user-interface  and  physical  levels.  At  least  three  tem¬ 
poral  query  languages  have  been  proposed  that  support  rollback  operations  [Ariav  1986,  Ben-Zvi 
1982,  Snodgrass  1987]  and  several  studies  have  investigated  efficient  storage  and  access  strategies 
for  temporal  databases  [Ahn  1986A,  Ahn  1986B,  Ahn  &:  Snodgrass  1986,  Ahn  &  Snodgrass  1988, 
Lum  et  al.  1984,  Rotem  &  Segev  1987,  Shoshani  &  Kawagoe  1986].  Also,  the  considerable  re¬ 
search  into  efficient  storage  and  access  strategies  for  persistent  data  structures  [Chazelle  1985,  Cole 
19S6,  Dobkin  &  Munro  1985,  Myers  1984,  Sarnak  &:  Tarjan  1986]  can  be  used  to  implement  our 
semantics. 

While  a  few  authors  have  envisaged  the  benefits  of  a  time- varying  scheme  [Ariav  1986,  Ben- 
Zvi  1982,  Shiftan  1986,  Woelk  et  al.  1986],  only  one  other  extension  of  the  relational  algebra,  that 
proposed  by  Ben-Zvi,  includes  support  for  an  evolving  scheme.  Ben-Zvi  proposes  that  a  temporal 
relation’s  scheme  itself  be  represented  as  a  temporal  relation,  thus  providing  a  uniform  treatment 
for  evolution  of  a  relation  and  its  scheme  [Ben-Zvi  1982].  B[e  does  not,  however,  provide  formal 
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semantics  for  scheme  evolution  in  the  context  of  general  support  for  transaction  time.  Gadia 
also  proposes  an  extension  of  the  relational  algebra  that  supports  transaction  time  but  does  not 
address  the  problem  of  scheme  evolution  [Gadia  k  Yeung  1988].  Martin  proposes  a  non-algebraic 
solution  to  the  problem  of  an  evolving  scheme  in  temporal  databases  using  modal  temporal  logic 
[Martin,  et  al.  1987],  A  scheme  temporal  logic  is  proposed  to  deal  with  changes  in  scheme.  A 
set  of  scheme  temporal  logic  formulae  are  associated  with  a  scheme  to  describe  its  evolution  and 
temporal  queries  are  interpreted  in  the  context  of  these  formulae.  This  approach,  unlike  ours, 
forces  synchronization  between  valid  time  and  scheme  changes.  Again,  formal  semantics  are  not 
provided.  Finally,  Adiba,  in  describing  mechanisms  for  the  storage  and  manipulation  of  historical 
multi-media  data,  advocates,  like  Ben-Zvi,  that  the  history  notion  used  to  model  changes  in  a 
database’s  contents  also  be  used  to  model  changes  in  its  scheme  [Adiba  k  Bui  Quang  1986]. 

While  there  has  been  significant  interest  in  database  reorganization  and  restructuring  [Baner- 
jee  et  al.  1987,  Markowitz  k  Makowsky  1987,  Navathe  k  Fry  1976,  Navathe  1980,  Shu  et  al.  1977, 
Shu  1987,  Sockut  k  Goldberg  1979],  such  approaches  have  assumed  that  the  scheme  (and  hence 
the  contents)  of  the  entire  database  will  be  modified  during  restructuring,  ensuring  that  only  one 
scheme  is  in  force.  Since  we  formalize  the  scheme  as  a  sequence  indexed  by  transaction  time,  sev¬ 
eral  schemes  can  be  in  force,  selectable  through  the  rollback  operator.  A  second  difference  is  that 
we  focus  solely  on  algebraic  support  for  scheme  evolution,  while  the  other  papers  considered  the 
related  issues  of  determining  what  changes  to  the  scheme  are  necessary  and  what  those  changes 
imply  regarding  the  new  state  to  be  calculated.  Certainly,  all  these  issues  must  be  addressed  before 
a  comprehensive  solution  to  scheme  evolution  is  developed. 

In  contrast  to  these  previous  approaches,  the  WAND  system  did  permit  several  generations 
of  schemes  to  be  simultaneously  present  [Gerritsea  k  Morgan  1976].  This  system  differs  from  our 
approach  in  two  respects.  First,  the  WAND  system  was  based  on  the  network  model,  whereas  our 
approach  is  based  on  the  relational  model.  More  significantly,  scheme  evolution  was  supported 
in  the  WAND  system  to  allow  dynamic  restructuring  of  the  database.  While  data  in  the  WAND 
system  could  also  be  associated  with  one  of  several  generations  of  schemes,  the  data  were  always 
restructured  to  match  the  most  recent  scheme  as  they  were  referenced.  Multiple  generations  were 
introduced  to  achieve  concurrency  between  restructuring  and  execution  of  application  programs. 
Hence,  the  underlying  model  did  not  support  transaction  time  or  rollback.  The  WAND  system 
was  effectively  a  snapshot  DBMS  that  permitted  applications  to  access  and  change  the  database 
while  a  global  restructuring  was  being  performed. 

ORION,  a  prototype  object-oriented  database  system  being  developed  at  MCC,  takes  a  similar 
approach  [Banerjee  et  al.  1987],  An  important  difference  is  that  when  the  scheme  in  ORION  is 
modified,  no  disk-resident  data  instances  need  be  updated.  Instead,  when  an  instance  is  referenced 
by  an  application  program  and  fetched  into  memory,  it  is  transformed  into  an  instance  conforming 
to  the  scheme  currently  in  effect.  Again,  only  one  scheme  is  ever  in  effect;  the  implementation 
places  the  burden  of  updating  the  data  across  a  scheme  change  on  subsequent  retrievals. 

Several  researchers  have  used  denotations!  semantics  to  define  formally  the  semantics  of  data¬ 
bases,  DBMS’s,  and  query  languages.  Subieta  proposes  an  approach  for  defining  query  languages 
formally  using  denotations!  semantics  [Subieta  1987].  This  approach  allows  powerful  query  lan¬ 
guages  with  precise  semantics  to  be  defined  for  most  database  models.  Rishe  proposes  that  de¬ 
notations!  semantics  be  used  to  provide  a  uniform  treatment  of  database  semantics  at  different 


information  levels  based  on  hierarchies  of  domains  of  mappings  from  “less  semantic”  representa¬ 
tions  of  information  into  “more  semantic”  representations  [Rishe  1985].  Neither  Subieta  nor  Rishe, 
however,  include  in  their  approaches  any  facilities  for  dealing  with  transaction  time  or  an  evolving 
scheme.  Lee  proposes  a  denotational  semantics  for  administrative  databases,  where  databases  are 
regarded  as  a  collection  of  logical  assertions  [Lee  1985].  Here,  the  denotation  of  an  expression  in  a 
first-order  predicate  calculus  is  based,  in  part,  on  its  evaluation  in  a  time  dimension,  analogous  to 
valid  time,  in  a  possible  world,  analogous  to  a  cross-section  of  a  database  state  at  a  transaction. 

An  obvious  next  step  would  be  to  implement  an  evolving  scheme  that  fully  supports  the 
rollback  operator.  One  approach  we  are  considering  converts  the  system  relations  in  our  prototype 
[Ahn  1986A]  to  be  rollback  relations,  rather  than  snapshot  relations  as  they  are  now.  Changes  to 
the  semantic  analysis  portions  of  the  query  analysis  would  be  required,  but  it  appears  that  changes 
to  the  backend  of  the  DBMS  would  be  minimal. 

Another  step  would  be  to  investigate  extensions  to  the  language.  A  straightforward  extension 
of  the  language  would  introduce  algebraic  operators  that  map  between  the  domain  of  snapshot 
states  and  the  domain  of  historical  states  directly.  The  introduction  of  such  operators  into  the 
snapshot  and  historical  algebras  would  render  the  algebras  multisorted.  Because  the  two  algebras, 
without  these  operators,  are  unisorted  and  because  we  wish  to  retain  thifproperty  for  the  algebras, 
we  have  elected  not  to  introduce  such  conversion  operators  into  our  language. 

A  second  extension  would  introduce  an  algebra  of  signatures,  analogous  to  the  algebras  of 
snapshot  and  historical  states,  to  remove  the  restriction  that  signature  specifications  in  the  com¬ 
mands  define_relation  and  modify_relation  be  a  relation’s  current  signature  or  a  constant. 
This  extension  would  support  signature  changes  dependent  on  both  the  current  and  past  signa¬ 
tures  of  relations  in  the  database. 

A  third  extension  would  remove  the  requirement  of  a  relation’s  scheme  being  constant  over 
the  transaction  interval  specified  in  the  rollback  operation.  The  major  problem  is  in  calculating 
the  scheme  for  the  resulting  relation.  A  general  but  simple  approach  has  not  yet  been  found. 

Finally,  the  effect  of  scheme  evolution  on  applications  programs  accessing  the  database  should 
be  considered  [Gerritsen  &  Morgan  1976].  Maintaining  consistency  between  such  programs  and  the 
database  scheme  becomes  more  difficult.  Similarly,  query  pre-compilation,  such  as  performed  in 
System  R  [Chamberlin  et  al.  1981],  may  or  may  not  be  effective,  depending  on  whether  the  time- 
stamps  provided  to  the  rollback  operators  are  constants  or  are  values  supplied  by  the  application 
I  program.  However,  it  appears  that  techniques  similar  to  those  employed  by  the  WAND  system 

and  ORION  could  serve  to  amortize  the  cost  of  scheme  changes. 
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A  Proofs  of  Language  Properties 


In  this  appendix,  we  provide  informal  proofs  for  three  properties  of  our  language,  stated  as  theorems 
in  Section  2.7. 


Theorem  1  The  language  is  a  natural  extension  of  the  relational  algebra  for  database  query  and 
update. 


PROOF.  First,  we  show  that  expressions  in  our  language  are  a  strict  superset  of  those  in  the 
relational  algebra.  Suppose  we  only  allow  expressions  involving  constants  that  denote  snapshot 
states,  identifiers  that  denote  relations  whose  current  class  is  snapshot,  and  the  five  relational 
operators.  Then,  expressions  in  the  language  are  exactly  those  allowed  in  the  relational  algebra. 
But  expressions  in  our  language  also  may  involve  constants  that  denote  historical  states,  identifiers 
that  denote  relations  whose  current  class  is  other  than  snapshot,  and  both  historical  and  rollback 
operators.  Hence,  expressions  in  our  language  are  a  strict  superset  of  those  in  the  relational  algebra. 

Next,  we  show  that  our  semantics  reduces  to  the  conventional  semantics  of  database  state  and  data¬ 
base  update  via  the  relational  algebra.  Suppose  we  restrict  the  class  of  all  relations  to  undefined 
and  snapshot.  Then, 
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(a)  The  signature  and  state  sequences  of  a  defined  relation  will  have  exactly  one  element  each,  the 
relation’s  current  signature  and  state.  The  relation  can  have  no  history  as  a  rollback  or  tem¬ 
poral  relation;  hence  its  MSoT  always  will  be  ((),(),() ).  Because  the  define_relation 
and  modify_relation  commands  change  a  relation’s  signature  sequence  by  appending  no 
more  than  one  element  to  the  relation’s  MSoT  signature  sequence,  these  commands  always 
will  produce  a  relation  with  a  single-element  signature  sequence.  The  same  holds  for  the 
relation’s  state  sequence. 

(b)  A  new  state  always  will  be  a  function  of  the  current  signature  and  state  of  defined  rela¬ 
tions  via  the  relational  algebra  semantics.  Both  the  define  .relation  and  modify_relation 
commands  determine  a  new  state  via  expression  evaluation.  The  only  semantically  correct 
expressions  are  those  involving  constants  that  denote  snapshot  states,  identifiers  that  denote 
relations  whose  current  class  is  snapshot,  and  the  five  relational  operators.  These  expressions 
are  exactly  those  allowed  in  the  relation  algebra,  their  value  depending  on  the  current  state 
and  signature  of  defined  relations  only. 

(c)  Deletion  will  correspond  to  physical  deletion.  The  delete  .relation  command  changes  a 

relation  by  appending  an  element  to  the  relation’s  MSoT  class  sequence;  it  never  adds  infor¬ 
mation  to  the  relation’s  signature  or  state  sequences.  The  delete  .relation  command  always 
will  produce  a  relation  whose  signature  and  state  sequences  are  empty,  which  corresponds  to 
physical  deletion  of  a  relation’s  current  signature  and  state.  | 


Theorem  2  The  semantics  of  the  language  minimizes  the  number  of  elements  in  a  relation’s  class, 
signature,  and  state  sequence  needed  to  record  the  relation’s  current  class,  signature,  and  state  and 
its  history  as  a  rollback  or  temporal  relation. 


PROOF.  Assume  that  the  number  of  elements  in  a  relation’s  class  sequence  exceeds  the  minimum 
needed  to  record  the  relation’s  current  class  and  its  history  as  a  rollback  or  temporal  relation. 
Then,  (a)  there  are  two  consecutive  elements  in  the  sequence  that  can  be  combined  or  (b)  there  is 
an  element  in  the  sequence  that  can  be  removed.  Consider  case  (a).  Consecutive  elements  in  the 
class  sequence  can  be  combined  only  if  they  record  the  same  class  over  non-disjoint  intervals.  But 
the  commands  only  append  a  new  element  to  a  relation’s  class  sequence  if  it  either  differs  from  the 
relation’s  MSoT  class  or  its  interval  is  disjoint  from  that  of  the  relation’s  MSoT  class.  Hence,  no 
two  consecutive  elements  in  a  relation’s  class  sequence  can  have  the  same  class  but  non-disjoint 
intervals.  Now,  consider  case  (b).  Commands  always  produce  a  new  relation  by  appending  new 
class  information  to  a  relation’s  MSoT  class  sequence.  But,  it  can  be  shown  that  all  elements  in  a 
relation’s  MSoT  class  sequence  record  intervals  when  the  relation  was  either  a  rollback  or  temporal 
relation.  Hence,  no  element  can  be  removed.  If  no  two  elements  can  be  combined  and  no  element 
can  be  removed,  our  assumption  is  contradicted  and  the  number  of  elements  in  the  class  sequence 
must  be  minimal.  Similar  arguments  hold  for  the  relation’s  signature  and  state  sequences.  | 


Theorem  3  Transactions  change  only  a  relation's  class,  signature,  and  state  current  at  the  start 
of  the  transaction. 


PROOF.  This  property  is  a  consequence  of  the  way  the  MSoT  function  is  defined  and  used.  We 
first  prove  the  property  for  a  relation’s  signature  sequence  and  then  for  its  class  and  state  sequences. 
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A  relation’s  current  signature  at  the  start  of  a  transaction  is  the  last  element  in  the  relation’s 
signature  sequence.  Assume,  therefore,  that  a  transaction  changes  an  element  that  is  in  the  rela¬ 
tion’s  signature  sequence  at  the  start  of  the  transaction  but  is  not  the  last  element  in  the  sequence. 
Such  a  change  must  occur  during  the  execution  of  a  command.  When  the  first  command  in  a 
transaction  executes,  MSoT  discards  the  last  element  in  the  relation’s  signature  sequence,  if  the 
relation’s  current  class  is  either  snapshot  or  historical.  Otherwise,  it  retains  all  the  elements. 
When  each  subsequent  command  in  the  transaction  is  executed,  MSoT  only  discards  any  element 
that  the  preceding  command  added  to  the  sequence.  Hence,  MSoT  never  changes  an  element  in 
a  relation’s  signature  sequence  that  precedes  the  last  element  in  the  sequence  at  the  start  of  the 
transaction.  Commands,  although  they  may  append  an  element  to  the  relation’s  MSoT  signature 
sequence,  never  change  existing  elements.  Hence,  commands  never  change  an  element  in  a  relation’s 
signature  sequence  that  precedes  the  last  element  in  the  sequence  at  the  start  of  the  transaction 
and  our  assumption  is  contradicted.  The  same  argument  holds  for  the  relation’s  state  sequence. 

The  above  argument  holds  for  a  relation’s  class  sequence  with  the  following  provisos.  When  the 
first  command  in  a  transaction  executes,  MSoT  discards  the  last  element  in  the  relation’s  class 
sequence  if  the  relation’s  current  class  is  undefined.  Also,  if  the  relation’s  current  class  is  either 
rollback  or  temporal,  MSoT  changes  the  last  element  in  the  sequence  to  “close”  the  interval 
assigned  to  the  relation’s  current  class  at  the  start  of  the  transactionr  When  each  subsequent 
command  in  the  transaction  is  executed,  MSoT  “re-do6es”  this  same  interval,  if  extended  by 
the  preceding  command.  Hence,  MSoT  never  changes  an  element  in  a  relation’s  class  sequence 
that  precedes  the  last  element  in  the  sequence  at  the  start  of  the  transaction.  Commands  may 
change  the  last  element  in  a  relation’s  MSoT  class  sequence  to  “extend”  the  interval  assigned  to 
the  class  component  of  that  element,  but  only  if  the  new  class  and  the  relation’s  MSoT  class  are 
equal  and  their  intervals  abut.  This  occurs  only,  when  the  last  element  in  the  relation’s  MSoT 
class  sequence  corresponds  to  the  last  element  in  the  relation’s  class  sequence  at  the  start  of  the 
transaction  (i.e.,  the  class  of  the  relation  at  the  start  of  the  transaction  was  either  rollback  or 
temporal).  Otherwise,  the  intervals  could  not  abut  as  there  would  exist  an  intervening  interval 
when  the  relation’s  class  was  either  snapshot,  historical,  or  undefined.  Hence,  commands  never 
change  an  element  in  a  relation’s  class  sequence  that  precedes  the  last  element  in  the  sequence  at 
the  start  of  the  transaction.  | 


B  MSoT  and  its  Subordinate  Functions 

In  this  appendix,  we  present  formal  definitions  for  MSoT  (Modified  Start  of  Transaction)  and 
its  subordinate  functions.  For  these  definitions,  let 

l  range  over  the  domain  SNAPSHOT  STATE  +  HISTORICAL  STATE , 
n,  n',  nj,  and  range  over  the  domain  TRANSACTION  NUMBER 1, 
m  range  over  the  domain  RECATION  SIGNATURE, 

u  and  u'  range  over  the  domain  [RELATION  CLASS  x  TRANSACTION  NUMBER]’ , 
v  range  over  the  domain  [RELATION  SIGNATURE  x  TRANSACTION  NUMBER)*, 


49 


I 

'  to  range  over  the  domain  [  [SMAVSHOT  STATE  x  TR.AMS ACTIO M  MUM B Ell)  + 

|  [HISTUniCAC  STATE  x  TH  AM S ACTIO M  MUM  BETl)  ]*,  and 

i  z  range  over  the  domain  HECATIOM  CCASS. 


MSoT  maps  a  relation  (it,  v,  to)  and  a  transaction  number  n  onto  the  history  of  the  relation  as  a 
rollback  or  temporal  relation  before  the  start  of  transaction  n. 

MSoT((tt,  v,  to),  n)  = 

if  ( tt ’  =  PREFIXCLASSES  (tt,  n)  A  tt'  #  (  )  A  n'  -  LASTTRNUMBER(tt')) 

then  if  MULTISTATECLASS  (LASTCLASS  (u')) 

then  (CLOSE  (tiy,  n  -  1),  PREFIXSIGS  (v,  n),  PREFIXSTATES  (to,  n)) 
else  (PREFIXCLASSES  (tt,  n'),  PREFIXSIGS  (v,  n'), 

PREFIXSTATES  (to,  n')) 

else  ((  ),(),(  )) 


PREFIXCLASSES  maps  a  relation’s  class  sequence  u  and  a  transaction  number  n  onto  the 
subsequence  recorded  before  the  start  of  transaction  n. 

PREFIXCLASSES  (tt,  n)  = 

if  (u  (  )  A  HEAD  (u)  =  (z,  rti,  TI2)  A  nj  <  n) 
then  HEAD  (tt)  ||  PREFIXCLASSES  (TAIL  (tt),  n) 
else  (  ) 


where  HEAD  and  TAIL  are  the  head  and  tail  operations  for  sequences  and  “||”  is  the  concate¬ 
nation  operator  on  sequences. 

PREFIXSIGS  maps  a  relation’s  signature  sequence  v  and  a  transaction  number  n  onto  the 
subsequence  recorded  before  the  start  of  transaction  n. 
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PREFIXSIGS  (v,  n)  = 

if  (v  ()  A  HEAD  (u)  =  (m,  ni)  A  tii  <  n) 

then  HEAD  (v)  ||  PREFIXSIGS  (TAIL  (u),  n) 
else  (  ) 


PREFIXSTATES  maps  a  relation’s  state  sequence  w  and  a  transaction  number  n  onto  the 
subsequence  recorded  before  the  start  of  transaction  n. 

PREFIXSTATES  (w,  n)  = 

if  (tu  ^  (  )  A  HEAD  ( w )  =  (/,  ni)  A  tii  <  n) 
then  HEAD  (to)  ||  PREFIXSTATES  (TAIL  (w),  n ) 
else  (  ) 


LASTTRNUMBER  maps  a  relation’s  class  sequence  onto  the  transaction  number  of  the  trans¬ 
action  that  appended  the  last  element  to  the  sequence.  If  the  relation’s  class  sequence  is 
empty,  LASTTRNUMBER  returns  error. 

LASTTRNUMBER  (a)  = 

if  (u  ?£  (  )  A  HEAD  (u)  =  (z,  m,  n2)) 
then  if  TAIL(u)  =  (  ) 
then  ni 

else  LASTTRNUMBER  (TAIL  (u)) 

else  ERROR 


LASTCLASS  maps  a  relation’s  class  sequence  onto  the  class  recorded  in  the  sequence’s  last 
element.  If  the  sequence  is  empty,  LASTCLASS  returns  error. 
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LASTCLASS  (u)  = 

if  (u  #  (  >  A  HEAD  O)  =  (z,  m ,  n2)) 
then  if  TAIL(u)  =  (  > 
then  z 

else  LASTCLASS  (TAIL  («)) 

else  ERROR 


CLOSE  maps  a  relation’s  class  sequence  u  and  a  transaction  number  n  onto  the  subsequence 
recorded  through  transaction  n.  It  also  sets  the  the  second  transaction-number  component  in 
the  last  element  of  th^  resulting  sequence  to  n  if  the  component  is  either  or  greater  than 
n. 


CLOSE  (u,  n )  = 

if  (u  /  (  )  A  HEAD  ( u )  =  (z,  r»i,  n2)  A  n\  <  n) 
then  if  TAIL(u)  ^  (  ) 

then  HEAD  (u)  ||  CLOSE  (TAIL  (tt),  n) 
else  if  (n2  =  -  V  (rc2  —  A  n2  >  n)) 
then  (z,  n-i,  n) 
else  (z,  ni,  n2) 
else  (  ) 


MULTISTATECLASS  is  a  boolean  function  that  determines  whether  a  class  is  either  rollback 
or  temporal. 

MULTISTATECLASS  (z)  = 

if  (z  =  ROLLBACK  V  Z  =  TEMPORAL) 
then  TRUE 
else  false 
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